[Standards] About stream namespaces

[Rachel Blackman]

>>>> 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.
>
> Sorry for being blunt:
>    If XML is too hard, then don't use it. ;-)

No offense taken.  But by that logic, if XMPP is too hard (because  
stripping namespaces out of top-level elements is difficult for you),  
then don't use *it*.  After all, this is the way it's presently  
defined.  It's not an insurmountable issue, obviously; I'm just  
contributing a data point that, no, changing the RFC doesn't make it  
universally easier.  I'm just saying, there's a reason a lot of  
clients did do it that way, not just 'because it was always done that  
way.'

Though really, my objection comes down to the fact that I don't think  
rewriting the RFC is where we should be spending our time.

Maybe I'm in the minority in this, but it still just seems to me more  
than a little silly (perhaps even wrong-headed) that we're focusing  
on trying to rip apart and redesign the things that are already in  
use, widely, and working.  XMPP streams are in use, widely, and  
working; every existing XMPP client uses them.  XEP-0115/CAPS is in  
use, widely, and working; many of the more common and popular clients  
support caps.  Etc.

But we're sitting here talking about throwing out or redesigning  
these in-use, working bits of our protocol, and meanwhile we have a  
situation where we STILL have the vast majority of XEPs completely  
unimplemented.

We're at a point where people start implementing non-standard  
variants on PEP-based XEPs (witness that iChat is now including PEP- 
based stuff like user tune right their presence stanzas) because no  
one supports PEP.  We have *two completely incompatible file transfer  
protocols*, which I'm surprised no one else seems to think is a  
potential interoperability problem down the road.  We have three  
(iChat, Gizmo, Google) AV stream technologies based on XMPP, all  
mutually incompatible.

I know I've been shot down before over this, but I /still/ feel we  
need a certification process to get people in line; a server that  
wants certification in a given year may have to add PEP if they want  
to be able to say 'XMPP Server 2008 Certified' or whatever.  A client  
that wants certification in a given year may have to add Jingle if  
they want to be able to say 'XMPP Media Client 2008 Certified' or  
whatever.  Even if we don't do certification, we need to sort out  
some of the growing incompatibilities; we already have clients who  
are adding their own mutant markup for sending images c2c embedded in  
messages, because we can't even seem to agree on a single c2c stream  
initiation system that would allow AIM-style 'direct connect' for  
sending images.  We have a ton of XEPs that people have written up as  
pie-in-the-sky ideas and that have never been implemented due to lack  
of PEP.  We now have -- I cannot stress this enough -- TWO MUTUALLY  
INCOMPATIBLE FILE TRANSFER PROTOCOLS.

Doesn't ANYONE else want to focus on those?  Anyone? :)

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