-----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: >> On Fri Apr 17 22:03:57 2009, XMPP Extensions Editor wrote: > >> 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?
I propose the following implementation note: In some conditions, an XMPP client or server might know that the sequence numbering is invalid (e.g., because of a catastrophic server failure). In these cases, the entity that discovers the problem SHOULD return a roster version of zero (in the case of the server) or request a roster version of zero (in the case of the client). 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 iEYEARECAAYFAknt4LcACgkQNL8k5A2w/vwB/gCgsCBH5LyCVPn1FrweZqMb1mdq ZpQAn3rEbrMcriqPzm7IhyHM2jhTJNxG =qObE -----END PGP SIGNATURE-----
