[Standards] About stream namespaces
elmex at x-paste.de
Fri Mar 16 19:12:55 UTC 2007
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
> >>>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
> 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
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
I also think that certification is a good idea.
More information about the Standards