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. 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". 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. Oh... and a typo: > During that time, the client might have received roster pushes related to > *varous* roster versions. Regards, George
