[Standards] Proposed XMPP Extension: Roster Versioning

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Thu Mar 6 02:30:08 UTC 2008


On Wednesday 05 March 2008 5:33 pm, Richard Dobson wrote:
> Peter Saint-Andre wrote:
> > Alexander Gnauck wrote:
> >> Peter Saint-Andre schrieb:
> >>> Here is revised text:
> >>>
> >>>    The value of the 'version' attribute SHOULD be a non-negative
> >>>    integer representing a strictly increasing sequence number that
> >>>    is increased with any change to the roster (whether or not the
> >>>    client supports this extension) but MAY be a unique identifer that
> >>>    is opaque to the client but understood by the server. In any case,
> >>>    the 'version' attribute contained in roster pushes MUST be unique.
> >>
> >> great, +1
> >
> > The Council didn't like the change from MUST to SHOULD as discussed here:
> >
> > http://logs.jabber.org/council@conference.jabber.org/2008-03-05.html#13:4
> >0:54
> >
> > Discussion can continue, naturally. :)
>
> Oh well thats a shame, just have leave it as my own extension.
> Implemented timestamps this evening to try it out and its working fine
> thus far.

I, too, don't understand why this value needs to be specified as being a 
strictly-increasing integer, if the intent is that clients should treat it as 
an opaque cookie thing anyway.

The argument is that allowing the value to be some free form string is 
unnecessarily flexible.  Sure.  However, I'd argue that requiring it to be a 
strictly-increasing integer amounts to overspecification, especially when we 
have an established trend of using free form strings all over XMPP.  I'd feel 
the same way if Dialback mandated a particular key format.  We don't 
need "nanny specs".

There's a big difference between avoiding overspecification (this) and being 
stupidly flexible (the joke in the council logs: "a stanza of type 
<message /> SHOULD be used, but another arbitrary string MAY be used, such as 
<thing />").

-Justin



More information about the Standards mailing list