[Standards] Proposed XMPP Extension: Roster Versioning

Peter Saint-Andre stpeter at stpeter.im
Wed Mar 5 00:40:05 UTC 2008

Richard Dobson wrote:
>> +1. I can't see any reason for the spec to require more than a
>> increasing version number.
> I would prefer if it were just an opaque string, certainly as far as the
> client in concerned there is no need for it to do anything other than
> store the most recent version identifier it has received and then return
> that to the server when required (i.e. at login), only the server needs
> to know what to do with it and this should certainly only be RECOMMENDED

Perhaps, I'll ponder that some more...

> What would happen in cases were the
> version number needs to be reset to 0 because someone has such a busy
> roster that over time they exhast the maximum integer value?

Even my roster isn't that busy. But yes it is *possible* I suppose.

> , or if
> maybe in future server implementors want to compress it somehow into hex
> or something similar, it would be far far better to leave this flexible
> and upto the server implementor on how they format the version identifier.

Sometimes flexibility comes back to bite you. I'd prefer to keep things
simple if we can. What does the extra flexibility really do for us, and
is it worth the cost?


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080304/cd7cf88a/attachment.bin>

More information about the Standards mailing list