Versioned Namespaces (was Re: [standards-jig] Avatars)

Evan Prodromou evan at prodromou.san-francisco.ca.us
Wed May 7 18:16:18 UTC 2003


>>>>> "JK" == Justin Karneges <justin-jdev at affinix.com> writes:

    JK> Hmm, but until a JEP status is changed to 'Active', the
    JK> semantics and syntax should be expected to change.
    JK> Experimental JEPs should not have to retain backwards
    JK> compatibility with earlier revisions of themselves.

That's the entire point. If you _don't_ have versioning of namespaces,
there's NO WAY for any processor to know that a partner in a
conversation is _really_ aware of the latest version of the protocol.

Quick example to illustrate the point: I create a remote bomb-defusing
JEP that allows people to safely disable an explosive devise using a
robot dog. The JEP defines one element, <disconnect>, with an
attribute, wire, which says which wire to pull.

      <iq from='person at example.com/DistantControlCenter'
          to='robotdog at example.net/AirportRunway'
          id='defuse_1'
          type='set'>

          <disconnect xmlns='jabber:iq:defuse' wire='yellow' />

      </iq>

      <iq from='robotdog at example.net/AirportRunway'
          to='person at example.com/DistantControlCenter'
          id='defuse_1'
          type='result'>

          <disconnect xmlns='jabber:iq:defuse' wire='yellow'>
             I disconnected the yellow wire. Woof.
          </disconnect>

      </iq>

Now, the JEP goes through a couple of versions. In version 0.1 of the
JEP, the default for the wire attribute, if unspecified, is "red". In
the 1.0 version of the JEP, it's "green".

Now, imagine that person at example.com has a client that implemented the
0.1 version of the JEP, and that the client author never bothered to
implement the full 1.0 version, or that the author mistakenly figured
that they were "compatible" (hey, I don't get any XML parse errors,
they must be compatible!), or that person@ never bothered to download
and install the latest version. robotdog at example.net, of course,
implements the full 1.0 version. 

So when person@ sends robotdog@ this IQ:

      <iq from='person at example.com/DistantControlCenter'
          to='robotdog at example.net/AirportRunway'
          id='defuse_2'
          type='set'>

          <disconnect xmlns='jabber:iq:defuse' />

      </iq>

...robotdog@ has NO WAY to know that person@ is talking in the _old_
JEP protocol and intends 'red' instead of 'green'. So the robotdog
pulls the green wire instead of the intended red wire.

      <iq from='robotdog at example.net/AirportRunway'
          to='person at example.com/DistantControlCenter'
          id='defuse_2'
          type='result'>

          <disconnect xmlns='jabber:iq:defuse' wire='green'>
             I disconnected the green wire. Woof.
          </disconnect>

      </iq>

      <presence from='robotdog at example.net/AirportRunway'
                to='person at example.com/DistantControlCenter'
                type='unavailable'>
          <status>KABOOM!!!!!!!!!!!!</status>
      </presence>

This is, obviously, a problem. Note that even though the robot dog
software is FULLY COMPLIANT with the snappiest, freshest, most
up-to-date version of the JEP, the poor pooch is still vaporized.

Now, let's say that instead of just using one namespace throughout the
life of the JEP, the author thoughtfully included a version in the
namespace. Thus, person@ would instead send this IQ:

      <iq from='person at example.com/DistantControlCenter'
          to='robotdog at example.net/AirportRunway'
          id='defuse_3'
          type='set'>

          <disconnect xmlns='http://www.jabber.org/jeps/jep-example.html#0.1' />

      </iq>

The implementors of the robot dog software have two choices. One is to
continue to support the old 0.1 experimental version of the protocol,
and disconnect the red wire which is default for that protocol:

      <iq from='robotdog at example.net/AirportRunway'
          to='person at example.com/DistantControlCenter'
          id='defuse_3'
          type='result'>

          <disconnect xmlns='http://www.jabber.org/jeps/jep-example.html#0.1'>
             I disconnected the red wire. Woof.
          </disconnect>

      </iq>

The other is to IGNORE stuff in the old version of the protocol:

      <iq from='robotdog at example.net/AirportRunway'
          to='person at example.com/DistantControlCenter'
          id='defuse_3'
          type='error'>

          <disconnect xmlns='http://www.jabber.org/jeps/jep-example.html#0.1' />

          <error code='501'>Not implemented.</error>
          
      </iq>

(Sorry for the old-style error.) Either way, nothing goes KABOOM.

Which strategy to use -- supporting experimental versions of the JEP
even when an active version is out, or just ignoring experimental
versions -- depends on how widespread implementations of experimental
versions are, and how valuable it is to accomodate them.

Note also that there is NO OBLIGATION on the part of implementors of
higher-version protocols to support older versions.

A last thing to note is that a disco-aware client on person@'s side
wouldn't even bother sending the old IQ in the first place:

      <iq from='person at example.com/DistantControlCenter'
          to='robotdog at example.net/AirportRunway'
          id='negotiate_1'
          type='get'>

         <query xmlns='http://jabber.org/protocol/disco#info'/>

      </iq>

      <iq from='robotdog at example.net/AirportRunway'
          to='person at example.com/DistantControlCenter'
          id='defuse_3'
          type='result'>

            <query xmlns='http://jabber.org/protocol/disco#info'>
            <!-- ... -->
                <feature var='http://www.jabber.org/jeps/jep-example.html#1.0' />
            <!-- ... -->
            </query>
      </iq>

Since the namespace is different, person@'s client won't try to use
the old version.

~ESP

P.S. I thought about changing this example to use Romeo and Juliet and
their mixup over the poison in Act V, but then I got confused and
used the robot dog example instead.

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






More information about the Standards mailing list