[Jabber-IETF] Agenda items

Pete Chown 1 at 234.cx
Fri Oct 4 09:28:41 CDT 2002


Iain Shigeoka wrote:

> For parsers yes, for data no. When we define XML data ala the XMPP protocol,
> we're really just selecting a subset of all possible XML data and calling it
> XMPP. In this case, the subset of XML is that which follows the XMPP DTDs
> and is used in a particular sequence.

Right, agreed so far.  There are valid XML documents that are not valid 
XMPP streams.

> It should be perfectly valid to select
> an even smaller subset and say that the document must be UTF-8, only the
> prefix "stream" can be used in the initial root element, and that it must
> exist within the etherx namespace.

You can do what you want, but this is not XML.  It may bear a 
superficial resemblance to XML, but it is not compliant with the 
standard.  Of course by "it" I mean the software, not the data.

You lose the benefit of layered protocols if you don't do the lower 
layers properly.  For example, XMPP runs over TCP.  TCP is in some 
respects rather complicated.  We could "simplify" it by insisting that 
XMPP software is not allowed to do explicit congestion notification.

This looks superficially like a simplification, but it would actually 
make things horribly complicated.  You now have to start fiddling about 
with TCP yourself, because you can no longer simply delegate it to the 
operating system's implementation.

The same thing happens here.  Rather than just using expat, and dealing 
with namespaces in the usual way, you have to roll your own.  Expat only 
deals with XML, it doesn't deal with "bogus XML" where namespace 
declarations don't mean what you expect.

> Any added complexity is entirely an issue of your parser design.

It's more complicated than this.  Software engineering practice says 
that you reuse code where possible.  You reuse XML code, and you reuse 
the operating system's TCP implementation.  Your suggestion forces 
everyone to develop new code to implement "bogus XML", with the inherent 
extra cost and increased bug counts.

> From a practical standpoint most current XMPP software won't accept anything
> but the standard namespace prefixes anyhow.  Why not standardize the
> practice (which is working well) rather than break it?

It works, but it's sub-optimal, because people end up writing more code 
than they need to.

>  I'd hate to see the IETF
> pass a standard that actually breaks most existing software implementations!

So would I.  I've no objection to the document noting the current 
practice.  At the same time, I believe future XMPP software should be 
required to implement namespaces properly.

I don't want to be too harsh about your idea. :-) I do see where you are 
coming from, because it isn't very easy to use standard XML parsers with 
XMPP.  I have to admit, I was tempted to propose a different solution, 
which would make each XMPP message its own document.  So rather than 
there being a single overarching "stream" document, there would be a 
sequence of short XML documents, with some kind of separator between 
them.  Sadly, I think this is likely to be too big a change to be 
acceptable to the Jabber community... :-(

-- 
Pete




More information about the xmppwg mailing list