[Standards] About stream namespaces

Rachel Blackman rcb at ceruleanstudios.com
Fri Mar 16 17:58:59 UTC 2007


>>> Enforcing this kind of backward compatibility for new client
>>> implementations does not make much sense for me. It would make more
>>> sense if servers would would be told that they MAY not generate
>>> such prefixes to take care of old clients.
>>>
>>> At least with that SHOULD NOT in place this issue will never be
>>> resolved because server implementors might say: "Well, RFC says you
>>> SHOULD NOT do that. I won't fix it.". And client developers will
>>> have to obey :-)
>>
>> One of our rules in writing the RFCs was not to break things since we
>> already had such a large installed base at that time. Sorry.
>
> Does this mean that these issues will never be resolved, because there
> are already so many people who do it wrong?

If it is defined as 'right' in the specification, people are not  
doing it 'wrong' to do it that way.

But the argument I hear is that more liberal XML should be allowed  
through because it's 'easier' for people.  But keep in mind, not  
everyone out there had the option of embedding a huge full XML/DOM/ 
XSLT/whatever-else library for XMPP.  For those who didn't,  
supporting looking for things via 'xmlns:caps' or 'xmlns:event' or  
'xmlns:status' or whatever else is rather more difficult.

Now, I personally already added support for that because we already  
have some clients which do send things like that in the stream, so  
whatever happens, I'll cope.  But since all I had for the  
circumstances in Astra was a really scaled-down EXPAT variant, it was  
a huge headache for me and required making my XMPP stream parser  
about four times more complicated than it would otherwise be.  I'm  
reasonably sure the same is true for folks on at least some mobile  
devices, who may have fairly scaled-down XML parsers as well.

Just as a data point that, no, changing the protocol to your method,  
to allow/want qualified elements and xmlns everywhere does not make  
implementation universally easier.  :)


-- 
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/





More information about the Standards mailing list