[standards-jig] JNG Ramblings.

Iain Shigeoka iain.shigeoka at messaginglogic.com
Wed Aug 14 03:21:19 UTC 2002


On 8/13/02 1:23 AM, "Wing, Oliver" <owing at vianetworks.com> wrote:

> Iain,
> 
>> PS - partly unrelated, but if we're going binary, I wonder if it wouldn't
> be
>> prudent to integrate addressing into the headers.  Perhaps some address
>> dictionary so that you could establish a per session mapping of routing ID
>> numbers to particular Jabber nodes/resources.  That way routing and
>> processing are completely separate activities and the router doesn't have
> to
>> understand XML.
> 
> Yes it would be nice to have addressing and packet types, which would make
> routing more efficent. However, I see a couple of issues
> 
> a) The XML still has to be passed at some point. You're simply moving where
> the processing takes place. As hildj has pointed out, scalability is already
> there and proven. (Some of the links recently posted to JDEV on SameTime and
> Exchange discuss performance of those products)

XML is still passed.  But XML doesn't necessarily need to be parsed.  For
example, if you know it is a message, it has a TTL of X, and a destination
of Y, you can deliver it without parsing the XML.  In fact, you don't really
care if it is XML which opens the possibility of pretty much sending
anything in a message, (the <message> xml being the default... But binary or
what have you is fair game).

> b) If you're putting addressing and/or packet types into the binary
> protocol, you must take it out of the XML protocol. If you have to leave it
> in there, checking for discrepencies should be done as early in the chain as
> possible. This defeats the 'router doesn't have to understand XML' gain.

Agreed.  Either it is in XML and you parse the XML or its in the binary
headers and not in the XML.  However, for security to be... secure, you'll
probably need to include the addresses in the XML as well (repudiation,
etc).  Unless you move security out to the binary envelope too...  At some
point everything is going to be binary at this rate.  :)

> c) The more binary information you add in, the further you move away from
> what Jabber is (not 'has been'). I see this thread turning from how to
> improve XMPP into a discussion for a completely new protocol (which by no
> means is necessarily a bad thing).

Well it depends on what you consider Jabber.  Many tightly associate Jabber
with the XML stream and so any of these is pretty much not Jabber.  I really
take it as the basic messaging model, and the base xml packet formats
<message> <presence> <iq> <error>.  So the framing, low level delivery
details, and transport of these packets is completely unattached to what is
Jabber...

-iain




More information about the Standards mailing list