[Jabber-IETF] Agenda items

Iain Shigeoka iain.shigeoka at messaginglogic.com
Mon Oct 7 00:27:39 CDT 2002

On 10/4/02 8:03 AM, "Peter Millard" <me at pgmillard.com> wrote:

> Pete Chown wrote:
>> Iain Shigeoka wrote:
>>>  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 know that the jabber community is looking hard at how to improve our
> namespace correctness, and the help of the WG would be greatly appreciated.
> It would be nice to lay out some kind of "migration plan" which doesn't
> break all current implementations, but outlines a way for us to get to be
> fully namespace compliant.


>> 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... :-(
> Lots of people in "jabber history" have looked at this solution since it
> solves the problem of being able to easily use existing parsers. However, in
> practice, (I've looked at prototypes that do this) spinning up a new parser
> instance for each packet is EXTREMELY more expensive than the current stream
> implementation. It's a much much more efficient solution. (Despite it being
> a pain to code for :)

I wonder how true this will be though with XML parsers starting to be
targeted towards web services work. I think going from static XML documents
to SOAP/XML-RPC is going to evolve parsers towards something that would be
highly efficient in handling separate small docs in the same connection.

BTW, Pete, you may be interested in the JNG (Jabber: Next Generation) and
Jabber Framing discussions we had in standards-jig about a month or so ago.
(Much of the discussion driven by Mike Lin's experimentation.) it's a pretty
good summary of the many discussions we've had to "improve" Jabber framing
to simplify implementation and increase server efficiency. In addition, I
think Jabber Inc has some mods to their server to basically do the same via
null terminated XML in order to support Flash Jabber clients using Flash
MX's XMLSocket.


More information about the xmppwg mailing list