[Standards] Proposed XMPP Extension: Roster Versioning
stpeter at stpeter.im
Wed Mar 5 15:47:16 UTC 2008
Richard Dobson wrote:
>> You just use a 128-bit unsigned integer. There is no upper limit here
>> - in particular, there is no upper limit specified anywhere in this
>> document - XSD merely states that a xs:nonNegativeInteger is a
>> sequence of digits, and has "countably infinite" cardinality.
>> If you really and truly believe that practical limits of 64-bit
>> unsigned integers can cause problems in the real world, I honestly
>> don't know what to say except show you the figures - you could have
>> thousands of updates every millisecond, and still last over half a
>> million years - 574,542 roughly, assuming a fixed year length of
>> 365.25 days.
>> I'm all for designing for the future, but you have to draw the line
>> somewhere, and besides, I figure we'll be on something bigger than
>> 64-bit well before then - a jump to 128-bit gains us 10^25 years of
>> breathing space, and I'd like to imagine we can think up a solution
>> within that time, assuming that's prior to the heat death of the
> Sure you can keep increasing the bit size of your integer in your
> implementation, but the spec still needs to dictate what happens once
> you reach overflow
In half a million years we'll be on XMPP version 168.9, won't we? ;-)
Why are we designing for such an eventuality?
> if its going to define that you have to implement it
> that way as well as how long the integer should be, although I still
> fail to see why strictly increasing numbers should be a MUST at the
> protocol level, IMO this is an internal server implementation issue and
> not a protocol one, im all for recommending that as a way for the server
> to implement it, but still don't think it should be MUST only RECOMMENDED.
If we change it to a SHOULD will that make people happier? We do
something similar in server dialback (recommend an algorithm for key
generation using HMAC-SHA256, but say you can use something else).
More arguments for using "a non-negative integer representing a strictly
increasing sequence number that is increased with any change to the
1. Code reuse
2. Server migration (yes, it happens, and it's painful enough as it is
without having to figure out a way to migrate opaque GUIDs from your old
implementation into strictly increasing sequence numbers in your new
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards