jdev - 2020-02-23

Is there a single client or server that is known to include cdata sections in its xml streams?

Not that I've ever seen. That would likely make it incompatible with most everything else

Do clients and servers generally support namespace prefixes other than the usual "stream" referring to "http://etherx.jabber.org/streams"? I mean, sending the whole namespace url every time seems kind of silly and also wastes traffic. One good example would be "<r xmlns='urn:xmpp:sm:3'/>". The namespace url is longer than the actual message. With prefixes it could be shortened to e.g. "<s:r/>"

Жокир, no.

last I tried that, things broke terribly

it’s also a SHOULD NOT in RFC 6120, if I recall correctly

ah, slightly different

from 4.8.5, RFC 6120 <https://tools.ietf.org/html/rfc6120#section-4.8.5>: > Interoperability Note: For historical reasons, an implementation MAY accept only the prefix 'stream' for the stream namespace (resulting in prefixed names such as <stream:stream> and <stream: features>); this specification retains that allowance from [RFC3920] for the purpose of backward compatibility. Implementations are advised that using a prefix other than 'stream' for the stream namespace might result in interoperability problems. If an entity receives a stream header with a stream namespace prefix it does not accept, it MUST close the stream with a stream error, which SHOULD be <bad-namespace-prefix/> (Section 4.9.3.2), although some existing implementations send <bad-format/> (Section 4.9.3.1) instead.

so you might face implementations which close your stream with <bad-namespace-prefix/> if you do that, however, I found that they may not do that and instead misbehave

jonas’, that section seems to talk only about the stream namespace prefix, not about additional namespace prefixes.

oh

right

wrong section

Жокир, I'd also expect that to be fragile, but we could add add a stream feature indicating support for this

I’m pretty sure that there was wording which discouraged or forbid usage of stream-level prefixes inside stanzas. And I’m also pretty sure that there was wording which discouraged use of stream-level prefixes altogether.

but I can’t find either

nevertheless, in practice, I’ve had issues with declaring namespace prefixes anywhere

https://xmpp.org/extensions/xep-0044.html flow

you’ve got my attention

jonas’ too.

> An implementation will need to maintain some sort of mapping between prefixes and namespaces, though some parsers, such as recent versions of Expat, can do this for the implementor.

oh my god, those must’ve been grim times

I’ll ask council to give me authorship of that thing

I want to clean it up and give it a stream feature and bring it to Draft

\o/ our saviour

is stream features enough? would that be so that you start a new stream knowing about it?

or continue in the same stream with it?

TIL about XEP-0044

pep., a client could abort the stream if the server doesn’t advertise it

*declaring* namespace prefixes on <stream:stream/> has typically not been an issue, but using them leads to fun behaviour

k

I even think there is no need to abort the stream/connection: implementations could just fallback to the default behavior and pretend that they never declared the namespace prefixes

and kudos to pep for digging out xep44 :)

it does not matter how long you are in this community, there is always one more XEP you didnt know about

flow, more annoying to implement though ;)

jonas’, actually I was just thinking about how to do it in smack, and at least here I don't think it would be that of an issue. The XML serialize already has knowledege about an xml environment which also holds the active namespace prefixes, so it's just a matter of zapping those again, if the server does not announce support for them

flow, in aioxmpp, it’d be a compile-time constant effectively. or a lot more code and slowness to include an optional "normaliser" at the serialisation level

hm, ok, zapping those is an interesting approach

flow, fwiw larma told me about it

credits where it's due

"zapping"?

pep., deleting them again from the xml environment

like they where never added in the first place

that should actually work without much overhead

If you intend to "zap" these namespaces then it means you have some kind of check in place to see if they're being used. So you'd have to check as long as your program runs. If you then zap them, you'd have to check that they're being zapped first

pep., I am confused, but I also think that this is not the case. Take Жокир example with SM: assume the SM namespace has been declared as prefix in <stream/>, if now the server does not support it, smack will just fallback to do what it already does

if the support announces support for it, then the serializer will emit <sm:r/> ✏

Emitting is fine yes, I'm talking about reading

ahh reading is a good point, a stream feature may not be enough in the c2s case, clients may want to tell the server that they support this

When receiving a stanza, if it's possible to have both, then I have to try both

but in reading the situation is similar

pep., no, you don’t have to "try"

pep., what is "both" here?

it’s unambiguous which serialisation variant is used and your XML parser will deal with it (if it supports it) and blow up otherwise

actually a full prefix aware parser should not blow up if you redundantly state the namespaces again

jonas’, ah wait, for some reason I had in mind that the namespaces themselves would change. Let me redo the maths with this info

anyhow, I think there is maybe a reason why we do not see widespread adoption of xep44: may parsers do not carry around the full context of the document

flow, yeah and maybe they should :x

Android XmlPullParser doesn't, and I wouldn't be suprised if Java's stax parser doesn't do also

is there no namespace-compliant parser in android? O_o

i.e. a thing which always gives you (namespace, local_name) instead of a qname?

I always read a qname as a namespace and a localpart (localname)

No the issue is that the parser would give you the localpart and the prefix

qname is prefix:localname, at least in my glossary

ugh

I hate those paresrs

we should all burn them

well I read qname as the thing that fully qualifies the name, so either a local-name and a namespace, or the triple of local-name, prefix, and the prefix-matching namespace

right, so, let me clarify:

anyhow, if the prefix is not declared within the same element, you may not get the namespace with some parsers

parsers which do not expose (namespace, local-name) tuples hassle-free everywhere and instead give you prefix+local-name shall burn in hell

the fuck what

seriously?

yeah there's no reason the application sees prefixes, it doesn't need them. Now that's a bit more complex because of us not doing 0044 already but..

pep., actually, you need prefixes in some XML applications such as SOAP

Json doesn't have namespaces therefore nothing needs them ever, if you are following along

Well you also need them in XMPP. If 0044 had been a thing from the start we wouldn't have. If people had fully supported namespaces we wouldn't have needed them.

flow, because they use prefixes in character data :(

jonas’, interesting, why do you *need* them in SOAP? ✏

Now we do, because we'll need to pass the info down to the XML parser at runtime

pep., incorrect, RFC 6120 ties the usage of namespaces down enough to not need them

you don’t need to know that the `stream:` prefix is used; the namespace is authoritative.

but you should use the `stream:` prefix for compat reasons

But yea I've dealt with various XML impls in Java that all seem to handle namespaces differently, or not at all, it's a bit of a nightmare

Right so in a way you do

pep., why?

What you just said, compat

just for the initial declaration

but that’s not for parsing, but for serialisation

Sure, that still means the application knows

yeah, that’s true

I was specifically talking about parsing though

k

serialisation is different, because you normally *want* to pass information about prefixes to the serialiser

the application knows better than the serialiser about which namespaces should be declared

(e.g. declaring the stream-management namespace on the stream:stream element, a serialiser can never guess that you’ll use that namespace often)

since declaring namespace prefixes is essentially an optimisation (unless you do namespaced attributes, where they’re required)

FYI, moparisthebest, stax appears to be fine

moparisthebest, http://paste.debian.net/1131699/

flow: https://github.com/moparisthebest/sxf4j 2012 looks like the last time I tried it, I think maybe half of those backends are unmaintained now...

moparisthebest, yeah, I think StAX's introduction in Java 8 helped here a lot

which was ~2014

This was with java6 too, seems like the dark ages now :)

it sure sounds like dark ages

So for Smack, I am probably going to support XPP3 for the next few years. Ideally the Android Platform would then provide the StAX API (after google moved a bit $$$ towards oracle potentially). Otherwhise one has to bundle another xml parser library for Smack on Android if I ever drop support for XPP3 ✏

I also could introduce namespace awareness in Smack's XPP3 compatiblity layer, hmmm

There isn't a single xep involving ns prefixes with attributes, is there? Can this xml feature be safely ignored then?