-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/27/09 5:27 PM, Jiří Zárevúcký wrote: > I've noticed change in this part: > >> the server MUST consider the item to have been modified and >> therefore MUST send the item to the client (typically via a roster >> push as described below). > > You changed the MUSTs to MAY, which again introduces several possible > problems. You can find reasons in one of previous threads.
Not everything needs to be a MUST. Please pay attention to the context. I take it that the text you refer to is this: *** If a series of roster modifications result in a roster item that does not differ from the version cached by the client (e.g., a modification to the item's 'name' attribute and then a modification back to the original value), the server MAY consider the item to have been modified and therefore MAY send the item to the client (typically via a roster push as described below). *** Now, what this means is that perhaps the roster hasn't "really" changed at all as a result of these modifications. If the server generates its version IDs based on a hash of the roster, then if I change a 'name' attribute and change it back the roster in fact hasn't changed at all (the version IDs are the same). Why would the server send a roster push to the client at that point? The roster is the same! Please try to formulate the appropriate text using MUST instead of MAY or SHOULD. > In addition, this passage doesn't make any sense after the change: > >> In addition, if the client signals a version ID that is different >> from the version 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 the empty string, thus bootstrapping the client's >> local cache. > > If the server uses incremental numbering and client returns a lesser > ver, it will always bootstrap, never sending incremental pushes. > Maybe it need rephrasing to something like "if server can't associate > the request to any previous version". You're right, that is nonsensical -- I must not have been paying close attention when I made that edit. I've changed it as follows: *** In general, unless returning the complete roster would (1) use less bandwidth than sending individual roster pushes to the client (e.g., if the roster contains only a few items) or (2) the server cannot associate the version ID with any previous version it has on file, the server SHOULD send an empty IQ-result and then send the modifications (if any) via roster pushes. *** > Also, I think the examples should still have the sequence numbers > (which is I believe preferred implementation). Use of hashes can be > noted in implementation notes. I disagree. The spec says that the version ID is opaque. If the examples include only version IDs that are *not* opaque, developers will ignore the text and focus only on the examples. > Oh... and a typo: > >> During that time, the client might have received roster pushes >> related to *varous* roster versions. Fixed. 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 iEYEARECAAYFAkn2ZgsACgkQNL8k5A2w/vyR0wCgwB+GbAcjc98ht38yDqnEJvtS 3QwAmwTaO+fzTJOkb/cUNXBRMjq3mfIw =VP5o -----END PGP SIGNATURE-----
