[standards-jig] JNG Ramblings

Iain Shigeoka iain.shigeoka at messaginglogic.com
Wed Aug 14 15:58:30 UTC 2002

On 8/13/02 11:40 PM, "Glenn Willen" <vyrus at bnet.org> wrote:

> stream tag. Why, then, is it neccesary to namespace it as <stream:stream>?
> A simple <stream> would be, if perhaps not valid XML (I'm not thoroughly
> versed in the subject) completely unambiguous. Yes, some parsers might not
> recognize it, but I'm willing to bet that most would accept it, or could
> be convinced to with an option, and it sounds like many of you write your
> own parsers anyway. The same goes for the xmlns and xmlns:stream
> attributes of the tag -- one of them is useful, but the other is always
> redundant -- why is it necessary? I will admit, again, to knowing only a
> little about xml, and next to nothing about namespacing -- would someone
> care to enlighten me, or point me in the right direction?

Jabber is currently "namespace inconsistent".  Parts of the standard either
aren't treating namespaces correctly, or are specifying details that should
not really be specified for XML.  Some of these details have probably leaked
into bug producing assumptions due to people rolling their own XML parsers.

A good example, is the opening stream tag.  From an XML standpoint, it
really should be a <stream> tag within the jabber.org/etherx namespace.  You
can use <stream:stream xmlns:stream="http://jabber.org/etherx">  However you
should also be able to use <foo:stream xmlns:foo="http://jabber.org/etherx">
and still comply.  However, because the standards all cite the stream:stream
syntax, I would bet that if you started to use a foo prefix you'd break a
lot of software that is out there today.

Theoretically, namespaces allow you to separate out your XML behavior.  So
although a <message> tag in the "jabber:client" namespace should trigger
normal Jabber packet delivery, a <message> tag in the
"foo.com/myownprotocol" namespace should be ignored by Jabber systems.

Thus you should be able to set the default namespace to
"foo.com/myownprotocol" and send Jabber packets as you would normally but be
assured that the packets should only be sent via servers and clients that
know your own protocol.  It looks like Jabber and smells like Jabber but it
isn't Jabber.  If any software in the pipeline between end points doesn't
support that namespace it should drop the packets.  You should theoretically
be able to use this to enforce who handles your packets (perhaps to create a
level of trust/security/quality of service).

And since you're in a standard Jabber stream, you can always fall back to
the standard jabber:client namespace to send the same data with less
guarantees about who is between you and the other end.  It is easy to
imagine a client that displays an icon (a lock or a speed symbol) to
indicate when you're on the specialized subnet, or another symbol to
indicate you have fallen back to standard jabber.

The relatively loose usage of namespaces in the current Jabber
implementations (mainly due to custom Jabber XML parsers which is mainly due
to the streaming document problems discussed in this thread) makes it pretty
unreliable to really exploit the possibilities that namespaces provides.
Hence, it looks (and for all practical purposes is) more like window
dressing right now.


More information about the Standards mailing list