[standards-jig] software version

Evan Prodromou evan at prodromou.san-francisco.ca.us
Sun Jul 27 18:20:26 UTC 2003

>>>>> "JM" == Julian Missig <julian at jabber.org> writes:

    Me> I completely understand that this is an backward-compatible
    Me> change for most implementations, but putting new elements into
    Me> an existing namespace is a habit we should get out of.

    JM> What?? Why?

Because being conservative in what you send and liberal in what you
accept is a fundamental principle of good network protocol
design. And, no, it doesn't count to expect the other guy to be

When a network node asks for 'jabber:iq:version' data, right now, it
means to return three data elements. What we're talking about is
returning an unexpected set of four or possibly five data elements
(additional <creator> and maybe <url>).

By separating the two different data sets into two different
namespaces, implementations can be _sure_ what set of elements to

We have a clean mechanism (disco) for determining what protocols a
network node can handle. A conversation about versions could easily
work like this:

     Node A                     Node B
     ------                     ------
                [disco get]

               [disco result]
            jabber:iq:version:2 (or whatever)

          jabber:iq:version:2 get

          jabber:iq:version:2 result

Another model -- less clean, admittedly -- is to just go ahead and
send the jabber:iq:version:2 namespace request, and if it comes back
with an error, fall back the jabber:iq:version request.

    JM> I think adding new elements that don't break anything is
    JM> perfectly acceptable.

Making assumptions about peer implementations -- that additional
elements "don't break anything" -- is bad protocol design. Yes, in
this case, adding additional elements _probably_ won't break
anything. In cases of other protocols, it may, and may not. We should
get used to using namespaces as markers for what exactly is requested
and exactly what can go in replies.

    JM>  That's one of the great things about the extensibility of
    JM> Jabber and XML. That's part of the reason I /started/ helping
    JM> out with Jabber to begin with.

That's a fascinating biographical tidbit, and when I write my magnum
opus "Lives and Motivations of Jabber Developers", I'll be sure to
include it as a footnote.

One could easily imagine a Jabber protocol where all the elements are
part of the main Jabber namespace. When we wanted to extend the Jabber
protocol, we would just throw elements into the mix, and hope everyone
else understands them. Alternately, we could do huge brontosauric
versioned releases of the protocol, with the entire protocol rigidly
defined. The first is more flexible (it's easy to add stuff); the
second is more reliable (you can depend on what's coming over the

The genius of Jabber is we get the advantage of _both_ protocol design
methods by dividing the protocol into *namespaces*. It's like a metal
chain: the individual units are rigid definitions in small namespaces,
but linked loosely together they form a flexible whole.

Implementations are reliable because they know exactly what to do with
a namespaced packet; they are flexible because they can choose which
namespaces to support, and can deal with unsupported namespaces in a
consistent and reasonable way.

I know that for version requests, this is probably not all that
important. But we have an excellent mechanism for making principled
extensions to Jabber that are forward and backward compatible. Why not
use it?


Evan Prodromou
evan at prodromou.san-francisco.ca.us

More information about the Standards mailing list