-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/21/09 8:47 AM, Peter Saint-Andre wrote: > On 4/21/09 7:53 AM, Peter Saint-Andre wrote: >> On 4/21/09 7:07 AM, Dave Cridland wrote: > >>> 3) We borrow text from RFC 4551, which has IPR implications. >> I think that we borrow a concept from 4551 but perhaps not exact text. >> I'll check on that. > > RFC 4551 defines CONDSTORE as follows: > > An IMAP server that supports this extension MUST associate a positive > unsigned 64-bit value called a modification sequence (mod-sequence) > with every IMAP message. This is an opaque value updated by the > server whenever a metadata item is modified. The server MUST > guarantee that each STORE command performed on the same mailbox > (including simultaneous stores to different metadata items from > different connections) will get a different mod-sequence value. > Also, for any two successful STORE operations performed in the same > session on the same mailbox, the mod-sequence of the second completed > operation MUST be greater than the mod-sequence of the first > completed. Note that the latter rule disallows the use of the system > clock as a mod-sequence, because if system time changes (e.g., an NTP > [NTP] client adjusting the time), the next generated value might be > less than the previous one. > > XEP-0237 defines 'ver' as follows: > > The 'ver' attribute is a strictly increasing sequence number that > is increased (but not necessarily incremented-by-one) with any > modification to the roster data. The value of the attribute MUST be > a non-negative 64-bit integer, MUST be changed only by the server, > and MUST be treated by the client as opaque. The server MUST ensure > that each change to the roster data will result in a different > sequence number and that the sequence number associated with a given > roster modification will be greater than the sequence number > associated with any previous roster modification. (Note: This rule > effectively disallows the use of the system clock as a sequence > number, since if the system time changes, e.g. because of an > adjustment based on an NTP update (see RFC 958 [4]), the next > generated value might be less than the previous one.) > > The borrowed text (as opposed to reformulated concept) is the > informational note about the the definition of 'ver' disallowing the use > of the system clock as a sequence number. I'd be just as happy to remove > that note entirely or to reword it in order to avoid any possible IPR > issues.
I propose that we add an implementation note that reads as follows (this really doesn't belong in the definition of the 'ver' attribute): An XMPP server cannot guarantee that a timestamp will be strictly increasing (e.g., the system time might change because of an adjustment based on an update triggered by the user of the Network Time Protocol (RFC 958 [4]); therefore, because the 'ver' attribute is defined as a strictly increasing sequence number, server implementations are advised to employ a method other than timestamps for generation of the 'ver' attribute. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknt4HgACgkQNL8k5A2w/vzf5wCfV+Hr7ywqB8ye7xN3IQh41y/c obsAn2gG3o0lTj6ygFkmeQ+6RZrOKfwL =LIMy -----END PGP SIGNATURE-----
