Spelling, tone, and grammar.
This problem of "downloading the world" (downloading the entire roster - every time a session is initialized or receiving an entire disco items + every time a session is initialized, or receiving an entire disco items response every time a MUC list is queried, etc.) was partially addressed by &xep0237; which was later merged into &rfc6121; ยง2.6. While this solved - the problem for the roster, it didn't account for other entities. + the problem for the roster, it did not account for other entities. Furthermore, roster versioning requires that the server maintain a great deal of state (roster items which should be pushed for each entity on - reconnect, or monotonically increasing counters, etc.) which can be - difficult to store or synchronize in a large, distributed system. This XEP - defines a method by which generic entity lists can be versioned and cached, - and which is optimized for distributed systems with large entity lists (but - works equally well on small, single server deployments). + reconnect, monotonically increasing counters, etc.) which can be difficult + to store or synchronize in a large, distributed system. + This XEP defines a method by which generic entity lists can be versioned and + cached which is optimized for distributed systems with large entity lists, + but which works equally well on small, single server deployments.
Servers that implement this protocol must assign such a version token to - each entity that is controlled by the server. The server SHOULD then - update this version every time any mutable property of the entity changes - (eg. when the subscription status of a user changes). The server MAY - choose to update this token at any time (to force the clients to - invalidate their cached representation fo the object). This version token - MUST then be included with every object representation of that entity - sent down in the stream. This is done by including a sub-node called - "version" qualified by the entity versioning XML namespace defined in - this document. Similarly, clients MAY also add version nodes for each - version token they possess to the request for a list (not specifying a - version token will force the server to send information on that entity to - the client). If a client sends up a list of version tokens, the server - MUST then check to see if those tokens correspond to any entity which it - knows about, and not send down any entities with matching version tokens - in the response. + each entity that is controlled by the server. + The server SHOULD then update this version every time any mutable property + of the entity changes (eg. when the subscription status of a user + changes). + The server MAY choose to update this token at any time (to force the + clients to invalidate their cached representation of the object). + This version token MUST then be included with every object representation + of that entity transmitted in the stream. + This is done by including a sub-node called "version" qualified by the + entity versioning XML namespace defined in this document. + Similarly, clients MAY also add version nodes for each version token they + possess to the request for a list (not specifying a version token will + force the server to send information on that entity to the client). + If a client sends up a list of version tokens, the server MUST then check + to see if those tokens correspond to any entity which it knows about, and + not send down any entities with matching version tokens in the response.
For example, a versioned roster request might look like this: