[Standards] Proposed XMPP Extension: Roster Versioning
stpeter at stpeter.im
Thu Mar 6 04:27:00 UTC 2008
Justin Karneges wrote:
> 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:
>>> 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.
A few hours of testing does not a reliable protocol make. Under what
conditions? Is this a public server that people can test against?
> 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.
I'm not convinced that that's the intent. It seems that it might be
useful in some situations for the client to know where it stands.
> 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".
We do need technologies that won't break.
> There's a big difference between avoiding overspecification (this)
I'll let Dave Cridland explain why he thinks this is not
overspecification. I think his experience with IETF email and data
storage protocols is relevant here. In particular, during the Council
meeting  he said:
"It's a lot more efficient with an int, and everything else is either
worse performance, fails entirely, or else is equivalent difficulty to
"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."
"Put it this way, since the counter-proposal involved timestamps, which
are known to be broken, I'm pretty sure people will get stuff wrong
without it being a MUST."
And previously on the list he said :
"strictly increasing numeric sequences have proved useful in the IMAP
world, because clients can spot when things go wrong much more easily."
"You can't use timestamps - they're not strictly increasing, for
Firstly, two roster changes could happen at precisely the same
moment. To be fair, by introducing cluster node identifiers, and
having a strict strong ordering of them, you could avoid this.
Secondly, the clock on a computer can, and surprisingly often does,
go backwards. That's a much harder problem to solve.
Thirdly, in a clustering situation, you'd have to ensure that the
time on each cluster node was perfectly synchronized.
So the closest you can do would be a modified timestamp that had
additional logic during generation to ensure it never went backwards,
in which case you don't need the cluster identifier anymore, and
that's effectively the same as having a strictly increasing integer
sequence anyway, so it's easier to just do that. But even if you did
want to use timestamps, just representing them as an integer is
pretty trivial. Look at the definition of "modtime" in ACAP (RFC
2244), which defines a strictly increasing modified timestamp
represented using digits."
I don't see that these concerns were addressed on the list. And I don't
see this as an appeal to authority or nannyism, just heeding the voice
> 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 />").
That was a reference to the backchannel discussions at the devcon, I
think. But I wouldn't know since I wasn't privy to the backchannel. :P
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards