[Standards] UPDATED: XEP-0237 (Roster Versioning)

Jiří Zárevúcký zarevucky.jiri at gmail.com
Sat May 9 18:52:45 UTC 2009

I have read the text again after a while and the following text got my

> 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


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.

More information about the Standards mailing list