I have read the text again after a while and the following text got my attention:
> 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 SHOULD NOT > consider the > item to have been modified for purposes of roster versioning and therefore > SHOULD NOT > push the item to the client in an interim roster push. That part is not very useful, since servers will hardly keep track of every previous roster version. I don't even want to think about the CPU overhead that will kill the cluster every 30 minutes (that's a hyperbole of course). The simplest "full featured" implementation consists of integer version numbers and "mver" field for every roster item. Server will then send all the items whose mver is greater than client's ver. Any throughout checking would hardly ever have any benefit. ----- About the opaque vs. integer examples dilemma. I think if someone really doesn't read the text, his implementation won't work at all anyway. The examples are kinda confusing this way. If you really want some opaque strings there, use "AAAAA", "BBBBB", "CCCCC" or something like that, so the sequentiality is obvious.
