-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/21/09 7:07 AM, Dave Cridland wrote: > On Fri Apr 17 22:03:57 2009, XMPP Extensions Editor wrote: >> Version 0.7 of XEP-0237 (Roster Versioning) has been released. > > A couple of minor points. > > 1) Roster pushes sent by the server MUST be sent in order of the ver > attribute.
I think we already say this: "When roster versioning is enabled, the server MUST include the updated roster sequence number with each roster push. Roster pushes MUST occur in sequence order and the sequence number contained in a roster push MUST be unique." > 2) There are cases where the sequence numbering can be known to have > broken, for example, if the account is destroyed and recreated, or in > the case of detectable data loss. > > In these instances, a client may ask for an old sequence number which is > in fact from a previous regime, meaning it will remain out of sync. > > This is not always a soluble problem - there are cases where the data > loss event is undetectable - if this is known to often be the case, I'd > advise avoiding the specification entirely. > > But for those cases where it's possible to detect a data loss event, it > may be useful to signal the sequence regime change. > > RFC 2244 provides no such mechanism - this isn't a tremendously good > thing, but it's hard to say how this affects real-world usage, given > there's only one ACAP server in existence, and I'm the only one who uses > it. > > RFC 4551 does, obliquely, because the UIDVALIDITY of an IMAP mailbox > controls the validity of the entire mailbox, including the MODSEQ values > (as well as all content). It's my impression that many existing mail > clients ignore this value, and don't suffer much as a result. > > We can either provide some similar mechanism, or we can advise > implementors of the risk, and advise them to have an option somewhere to > "blow away the cache". I think that in our context blowing away the cache would mean setting ver='0' on a roster get. It's not clear to me what our cases of detectable data loss are (and how the client would detect it). In the case of the account being destroyed and re-created, or of the server simply losing its knowledge of the sequencing because of a catastrophic failure, perhaps the server could return ver='0' on a roster result? > 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. > To the best > of my knowledge, the text was written by Alexey Melnikov, and as such, > the copyright is owned by Isode Ltd, IANAL but the Copyright Notice on RFC 4551 says: Copyright (C) The Internet Society (2006). > and Isode's default policy WRT SDOs > applies - ie, Isode will grant whatever permission, license, disclaimer, > or assignment is required. OK, great. 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 iEYEARECAAYFAkntz9cACgkQNL8k5A2w/vzGpwCcC2eTlogR4akrZzvagoLstXp0 N74AoLVTl6OqQNG4rasOz/Ywbk+DLxZd =aI6J -----END PGP SIGNATURE-----
