-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. On a separate note, the phrase "any previous roster modification" might be problematic (what if the server needs to reset the sequence number back to zero?). I propose that we change it to "any previous roster modification for this session" (where the definition of a session is borrowed from RFC 3921 / rfc3921bis). 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 iEYEARECAAYFAknt3HQACgkQNL8k5A2w/vzDIgCgx6nSupMMVSqgBwjlsHUP2Y3I woAAnA7gALSMaHyHqNRIvYakAPRUCPcp =ubVs -----END PGP SIGNATURE-----
