[Standards] About stream namespaces

[Robin Redeker]

On Fri, Mar 16, 2007 at 11:42:15AM -0700, Rachel Blackman wrote:
> >>>>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*. 

I meant the usage of XML in XMPP. XMPP is indeed damn hard compared
to some other protocols. For example because you can't just get up
any XML parser/writer and just write the stuff out without taking
_much_ care on the generated XML.

I can cope with the weirdness of "XML" in XMPP by implementing some
hacks here and there. I just wanted to bring up this point and
wanted some clarification.

I can only speculate about the reasons why XMPP is what it is today.

> 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.

Do whatever you want with your 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.

I agree if you call that working.

> 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.

It's just me I guess :-)

> 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.

If changing the RFCs is out of question I agree that PEP is quite
high priority :-) And my client library will propably support PEP
once I implemented the bits of the core solidly. And I found a server
I can test with...

> 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.

I also think that certification is a good idea.


Robin