2009/4/21 Peter Saint-Andre <stpe...@stpeter.im>: > 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. The local corrupted cache scenario is already in the spec (under request example). No need to include it again.
