On Jul 4, 2006, at 1:50 PM, Ralph Meijer wrote:
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 againstWildfire 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 theserestrictions could be relaxed in a new version of the RFC (which wouldnot be a problem for any software using a compliant XML parser).This is mostly for compatibility with pre-XMPP implementations of the Jabber protocols. Some of the elders might expand on this. Changing this requirement would surely break most of the current implementations out there. It basically comes down to the good old: be conservative with what you send, liberal with what you except.
Actually, there's another reason as well. Particularly if this stanza is going to be forwarded on as a part of another stream, that stream probably won't have the correct namespace prefixes defined. It was easier to put this restriction in than to specify some sort of canonicalization rules for stanzas.
-- Joe Hildebrand
smime.p7s
Description: S/MIME cryptographic signature
