-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/21/09 2:58 PM, Jiří Zárevúcký wrote: > 2009/4/21 Peter Saint-Andre <[email protected]>: >> -----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. > > That's the general idea.
OK, I will adjust the text a bit further, then. >> 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? >> > > I the server's database gets corrupted or lost, it doesn't know the > correct roster for that sequence number anyway, so it is pretty > implicit to revert it to the last known uncorrupted version (if any > exists.. backup for example? does not necessarily need to be zero). > But it doesn't hurt to make it explicit, too. > > There could be another problem, though. If the roster got reverted, > some client could update it up to the original sequence number or > further. Then if some client that wasn't used for long time came > online, it could receive wrong updates. I think it is up to the server to return the complete roster in this case. > Is such scenario worth attention? I don't know how often could > something like that happen. The only way to fix it (I can think of) > would be including some identifier of roster (another number?) that > server would have to reset in case of any failure/reverting. The > client would then send requests based on both roster's ID and sequence > number. But I don't like the idea much. Yeah, I don't like that, either. Perhaps the solution is to use a better server. :) 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 iEYEARECAAYFAknuQ6kACgkQNL8k5A2w/vxijACg29Q5py/6xqkqrJ5nsBrzi5/t 3w8AniYQzciq9ISL8rgQNrkfNarjw5fJ =dX4b -----END PGP SIGNATURE-----
