[Jabber-IETF] Agenda items
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
> 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... :-(
More information about the xmppwg