Hello all, I've been working on a new XMPP library implemented using ElementTree, a very nice XML library which uses the expat parser underneath, and which has found such widespread use that it will be in the Python 2.5 standard library. It is coming along nicely, and I will be releasing it as open source pretty soon. Let me know if anyone is interested.
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" /> Why was the choice made to impose this restriction on XMPP's use of XML? 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?). Anyway, I wonder why it was done this way 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). Regards, Manuzhai
