[jdev] Limitations of XML Namespaces use

[Peter Saint-Andre]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Manuzhai wrote:

> Now, today I found a message by Ralph Meijer on this list pointing to
> section 11.2.2 in RFC 3920, and I was very much surprised by this. I am
> talking specifically about this restriction: "An implementation MUST NOT
> generate namespace prefixes for elements in the default namespace if the
> default namespace is 'jabber:client' or 'jabber:server'. An
> implementation SHOULD NOT generate namespace prefixes for elements
> qualified by content (as opposed to stream) namespaces other than
> 'jabber:client' and 'jabber:server'." and the one in 11.2.3.
> 
> The XML restrictions in 11.1 make a lot of sense given the structure of
> XMPP streams, but it seems very weird to significantly cripple the use
> of XML namespaces in XMPP streams with these restrictions. With the XML
> namespaces spec (in widespread use, I'd say), these are equivalent:
> 
> <ns0:message xmlns:ns0="jabber:client" />
> <message xmlns="jabber:client" />

Yes, we realize those are equivalent.

> Why was the choice made to impose this restriction on XMPP's use of XML?

Mostly, backwards-compatibility with "XMPP 0.9", i.e., the installed
base of Jabber software existing when we worked on the XMPP specs within
the IETF. Why break things if there's no good reason to do so? We had a
kind of Hippocratic oath in working on the RFCs: "first, do no harm".

> Given the importance of XML namespaces throughout the XMPP protocol, it
> doesn't make a whole lot of sense to me. I developed my client against
> Wildfire Server, and it does the right thing, but I already ran into
> some problems with ejabberd concerning the starttls tag (but then
> starttls is not in the jabber:client namespace, so the restrictions
> shouldn't apply to it, right?).

The starttls and sasl stuff is "pre-stanza", i.e., a stanza is defined
as an <iq/>, <message/>, or <presence/> packet.

> Anyway, I wonder why it was done this way 

Joe mentioned content forwarding. If my client "negotiates" ns0 for the
jabber:client namespace, then my server will probably need to strip off
the prefix in order to send stanzas over a server-to-server link to
another domain. That's more processing power required for a
transformation that doesn't buy us anything (AFAICS).

> and I am hoping that these
> restrictions could be relaxed in a new version of the RFC (which would
> not be a problem for any software using a compliant XML parser).

Not likely, but you are free to argue for it when we work on rfc3920bis.
(The best place is the xmppwg at jabber.org list.)

BTW, http://www.jabber.org/jeps/jep-0044.html may be of interest if you
decide to make the argument. :-)

Peter

- --
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEq/3DNF1RSzyt3NURApaqAJwOmLI7n0vByuRQWvDI9YQ+wC06AgCcCHpX
KxlFCD44uM0h9RtPsbbe9kg=
=lslf
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://www.jabber.org/jdev/attachments/20060705/4336afb0/attachment-0002.bin>