-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/21/09 4:07 PM, Peter Saint-Andre wrote: > On 4/21/09 2:58 PM, JiYí 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, JiYí 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.
Done. Currently I have this in my working copy: *** 2.3 Server Response Whether or not the roster has changed since the version enumerated by the client, the server MUST either return the complete roster as described in RFC 3921 or return an empty IQ-result (thus indicating that any roster modifications will be sent via roster pushes, as described below). In general, unless returning the complete roster would use less bandwidth than sending individual roster pushes to the client (e.g., if the roster contains only a few items), the server SHOULD send an empty IQ-result and then send the modifications (if any) via roster pushes. In addition, if the client signals a sequence number that is greater than the sequence number currently on file at the server for that JID, the server MUST return the whole current roster as if client announced its version to be zero, thus bootstrapping the client's local cache. *** 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 iEYEARECAAYFAknudCUACgkQNL8k5A2w/vyPYACglqiCfSaCgapClp6P6JzVmR6e iuIAoPPfOcyMGOR77M7ZifG8qkbNrSQ6 =Ebjh -----END PGP SIGNATURE-----
