-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/21/09 12:57 PM, Jiří Zárevúcký wrote: > 2009/4/21 Peter Saint-Andre <[email protected]>: >> 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 >> > > That doesn't seem very clear to me. And what if the roster was already > modified with another client? I think that better formulation would be > something like: > > If client announces it's version number to be bigger than the > version of currently server-side stored roster (for example because a > catastrophic server failure erased all roster information), the server > MUST return the whole current roster as if client announced it's > version to be zero, thus bootstrapping client's local cache.
Something like that is good for the case when the client sends a roster request with a version number greater than what the server has on hand. But are there other cases of corrupted / invalid sequence numbering on server side? Or do we say that in such cases the server needs to in essence reset its sequence number back to zero? > The local corrupted cache scenario is already in the spec (under > request example). No need to include it again. Good point. 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 iEYEARECAAYFAknuGaIACgkQNL8k5A2w/vwEnQCgzxKvgn5d6zSH4yXEZabQczRG eAgAnRb+fhfG3nOeh/qbODoX0aIKZWiZ =pwq3 -----END PGP SIGNATURE-----
