[Standards] Proposed XMPP Extension: Roster Versioning

Dave Cridland dave at cridland.net
Thu Mar 6 11:53:36 UTC 2008

On Thu Mar  6 07:50:32 2008, Justin Karneges wrote:
> What counts as what is a matter of what the usual design practices  
> and trends are for related specifications.  My assessment, from  
> what I read in the mailing list arguments, is that opaque was in  
> the 'neutral' category.  Thus it should not be Richard that needs  
> to argue for opaque, but rather it should be Dave that needs to  
> argue for integer.  IMO, I guess.

I wouldn't put my name to it, but I suspect that merely "unique" is  
sufficient to avoid breakage in the client, although it'll produce a  
fairly inefficient protocol, equivalent to a simple  

It's possible - but again, I wouldn't put my name to it - that  
"strictly non-decreasing" is okay, too. I'm a lot less sure about  
this, I've not thought too hard about the failure cases. I think this  
would yield inefficiency, too, but I think it might not break  
anything. Perhaps.

For efficiency, then, you need a strictly increasing sequence, which  
has the useful property that it's known to work in several use-cases  

Now, potentially, this need not be a non-negative integer sequence,  
but non-negative integer sequence is, by far, the simplest one to  
implement, and has the convenient property that we know where it  
starts. They're a lot easier to implement than a modified strictly  
increasing timestamp. (I know, I've done both).

There's the other advantage that strictly increasing integer  
sequences are very well understood, having been used in various  
places for a couple of decades for synchronization in network  
protocols. (The IMAP UID[NEXT] is one such, as is the more recent  
[HIGHEST]MODSEQ, used in real deployments. ACAP used a strictly  
increasing timestamp-derived value, and this is not only more  
complicated to increment, it's also slower, mandating a system call  
in addition to the contention point, and is nightmarishly difficult  
to explain clearly in a specification, and finally, it's not really  
quite an integral value, and instead needs comparing as a string, not  
an int)

Now - should a client be able to compare two sequence values and see  
which one is higher? If so, we want a clearly defined sequence, if  
not, we don't care.

Well, this has been the case for IMAP UIDs for years, and is  
remarkably handy in this particular instance, but that's unfair -  
UIDs are, by intent, designed for this.

IMAP CONDSTORE was long thought to be able to be implemented in the  
client as pure strings. My own client implementation does actually  
compare values in a few cases for efficiency - and I'm only doing the  
synchronization side of CONDSTORE, which is equivalent to what we're  
doing here. I'd hate to discover late in the day that we actually  
need to do this.

The assertion that by allowing client-side comparison of sequence  
values it's possible to introduce bugs is an interesting one, but as  
far as I can tell, baseless - it's yet to cause a problem in IMAP  
CONDSTORE or ACAP modtime, and indeed has actually been a bit of a  
benefit. Still, I'd be happy if there were a directive that clients  
SHOULD NOT compare locally.

One case where client-side comparison of sequence values is very  
useful indeed is for external testing - it makes it much easier when  
you can perform simple verification. Recently, we've seen an upsurge  
in wire-based external testing/validation tools in IMAP, and they've  
proven very useful for server developers.

So I'd lean toward "does no harm", and "can be useful in some  
circumstances", and therefore we need a well-defined strictly  
increasing sequence.

There are many such sequences, however, but the one that strikes me  
as most useful is an integral one. Life because even easier when we  
know of a particular value which is lower than or equal to all others  
in the sequence, too.

So, in conclusion, I'll stick to my guns and say we want a strictly  
increasing integer sequence.

> > "One interesting point is that with an int, there's always  
> something a
> > client can use to get the entire roster, with versioning turned  
> on."
> >
> > "I'm not quite sure what the client ought to send if everything's
> > completely opaque - it'd need more syntax."
> Maybe these could be explained here on the list.  The implication  
> in these statements is that the revision value has meaning to the  
> client, and that the client can even create these values.

Yes, it can, in one case - where it wishes to specify a sequence  
value that occurs prior to all others. Clients use this in the spec  
as written to request all updates from a sequence value lower than,  
or equal to, all possible sequence values.

(This does, to be fair, break pre-populated rosters in a naïve  
implementation - if your server does prepopulated rosters, like  
shared rosters, you'll need to update the sequence when you  
[pre-]populate externally.)

We can do this bootstrapping in two ways. Either a special attribute  
value is chosen which has the fixed property of comparing equal to or  
lower than any valid value of the sequence, or else we signal this  
using a different attribute.

With an integer sequence, you can choose "0". We could also force the  
sequence to begin with "1" - a non-zero non-negative strictly  
increasing integral sequence - which'd help those servers which  
prepopulate rosters.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list