[Standards] Proposed XMPP Extension: Roster Versioning

Richard Dobson richard at dobson-i.net
Thu Mar 6 09:45:17 UTC 2008

> A few hours of testing does not a reliable protocol make. Under what
> conditions? Is this a public server that people can test against?
No you are correct, but even so the tone of some of the messages on this 
subject as far as I read them said that it wouldn't work, and under my 
limited testing it does seem to. I can make it publically accessible if 
you like and actually want to and will have a go.

> 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.
Then id suggest that gets specified in the spec.

> We do need technologies that won't break.
Sure but it hasn't been fully explained why it would break.

> "It's a lot more efficient with an int, and everything else is either
> worse performance, fails entirely, or else is equivalent difficulty to
> an int."
What sort of things are these? Im not trying to say im right and he's 
wrong but id like a more full explanation on the points above and below 
so I can understand why Dave thinks it will break, because as far as I 
can see all the problems pointed out so far in this thread can be easily 

> "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."
Yea it can just omit the version attribute.

> "I'm not quite sure what the client ought to send if everything's
> completely opaque - it'd need more syntax."
What kind of syntax were you thinking of?

> "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."
Why are they broken?

> And previously on the list he said [2]:
> "strictly increasing numeric sequences have proved useful in the IMAP
> world, because clients can spot when things go wrong much more easily."
Ok thats certainly fair enough, although it would be good to specify 
that in the spec.

> And [3]:
> "You can't use timestamps - they're not strictly increasing, for
> various reasons.
Why does it have to be strictly increasing, even if it was a timestamp?

> 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.
Why is it a problem if two updates share the same version identifier? 
Couldn't they not just become part of a single atomic change?

> Secondly, the clock on a computer can, and surprisingly often does,
> go backwards. That's a much harder problem to solve.
As previously requested could you describe this further or point to some 
more information on this so I can understand how much of a problem this 
actually is.

> Thirdly, in a clustering situation, you'd have to ensure that the
> time on each cluster node was perfectly synchronized.
No they don't as previously pointed out (the database layer could 
generate all the ids).

> 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."
Yup exactly so the issue about clocks going backwards can be easily 
overcome then.

> 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
> of experience.
I did respond similar to above, but didn't see any response to my 
questions, I would appreciate some answers so I can at least understand 
where Dave is coming from.

Is there any chance we can use BASE64 or something to compress the 
version identifiers in the roster pushes and whatnot?, just like is done 
with the hashes in caps? Or do we think its probably not really going to 
be a problem in the future? Granted as an auto incrementing integer it 
probably wont be much of an issue unless you have an incredibly busy 
roster, just trying to plan ahead.


More information about the Standards mailing list