[standards-jig] software version

Evan Prodromou evan at prodromou.san-francisco.ca.us
Mon Jul 28 11:10:13 UTC 2003

>>>>> "JK" == Jacek Konieczny <jajcus at bnet.pl> writes:

    JK> And now:
    JK> - disco feature list grows and grows

Taken to its logical conclusion, your objection seems to suggest that
we should never create or implement new namespaces. Is bandwidth usage
in disco results really that humongous?

    JK> - clients need not only implement current jabber:iq:version,
    JK> bug jabber:iq:version and jabber:iq:version:2.

No, they don't. They can implement either, or both, or neither.

I see a curve for adoption of protocols that overlap in functionality
something like this (with apologies to those who use proportional

    ^ | 111111121212121222222222222222
    | |      2         1
    u |     2           1
    s |    2             1
    a |   2               1
    g |  2                 11111111111
    e | 2
        time ->

At first, everyone has version 1, and only a few bleeding-edge types
implement 2. As 2's usage grows, it becomes more useful, and more
implementors include it. For a while, it's necessary to implement both
-- 2 to get the extra features, and 1 for talking to old

Gradually, new implementors stop bothering with the 1 standard, since
everyone worth talking to now uses 2 and it's got more features,
anyways. Existing implementations start to pull out their old 1 code,
since it's bitrotting and it's not that useful any more. 1
implementations go down in percentage, and eventually level off to
those people who haven't upgraded their software since 1999.

Another mitigating factor is standards collections like Jabber IM
Basic 1.0. These will say what namespaces you "should" implement, and
will help introduce new protocols and push obsolete ones off the
Jabber network.

    JK> If we do the same for other protocols clients will have to
    JK> implement lots of nearly-the-same protocols. This doesn't look
    JK> clean to me.

Look at jabber:iq:agent[s], jabber:iq:browse, and disco. The three
protocols (more namespaces, though... five?) meet more or less the
same needs. Browse gradually replaced agents, and disco is gradually
replacing browse. It's not an insane model to follow; in fact, it
seems to work quite well.

IWBNI we got our protocols exactly right every time. But we don't, and
things change. We can either deal with the change in a principled way
that makes it easy for everyone to adopt them at their own pace, or we
can just throw stuff into the mix and laugh at the goobs whose
software breaks because of it.

    JK> Even XMPP specs say that protocol elements don't have to be
    JK> valid against provided schemas and that implementations should
    JK> not assume they are valid.

Yes, but as long as we're quoting scripture, I'll note that "Clients
SHOULD NOT rely on the ability to send data which does not conform to
the schemas [...]". Be liberal in what you accept, and conservative in
what you send. It's really a simple principle.


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

More information about the Standards mailing list