XEP-0366: Editing for spelling, tone, and grammar

This commit is contained in:
Sam Whited 2016-12-09 14:23:32 -06:00
parent 9dbc111ec3
commit e94d337aff
1 changed files with 34 additions and 30 deletions

View File

@ -26,10 +26,12 @@
<supersededby /> <supersededby />
<shortname>EV</shortname> <shortname>EV</shortname>
&sam; &sam;
<author> <revision>
<firstname>Doug</firstname> <version>0.1.2</version>
<surname>Keen</surname> <date>2016-12-21</date>
</author> <initials>ssw</initials>
<remark><p>Spelling, tone, and grammar.</p></remark>
</revision>
<revision> <revision>
<version>0.1.1</version> <version>0.1.1</version>
<date>2016-07-11</date> <date>2016-07-11</date>
@ -59,17 +61,17 @@
<section1 topic='Introduction' anchor='intro'> <section1 topic='Introduction' anchor='intro'>
<p> <p>
This problem of "downloading the world" (downloading the entire roster 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 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 &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 Furthermore, roster versioning requires that the server maintain a great
deal of state (roster items which should be pushed for each entity on deal of state (roster items which should be pushed for each entity on
reconnect, or monotonically increasing counters, etc.) which can be reconnect, monotonically increasing counters, etc.) which can be difficult
difficult to store or synchronize in a large, distributed system. This XEP to store or synchronize in a large, distributed system.
defines a method by which generic entity lists can be versioned and cached, This XEP defines a method by which generic entity lists can be versioned and
and which is optimized for distributed systems with large entity lists (but cached which is optimized for distributed systems with large entity lists,
works equally well on small, single server deployments). but which works equally well on small, single server deployments.
</p> </p>
</section1> </section1>
@ -79,7 +81,7 @@
An extra round trip MUST NOT be required to initiate entity versioning. An extra round trip MUST NOT be required to initiate entity versioning.
</li> </li>
<li> <li>
Clients that do not implement the protocol (but which use servers that Clients that do not implement this protocol (but which use servers that
do) MUST still be able to request and receive entities normally. do) MUST still be able to request and receive entities normally.
</li> </li>
<li> <li>
@ -124,9 +126,10 @@
<ul> <ul>
<li> <li>
A client on a mobile device where bandwidth and throughput are limited A client on a mobile device where bandwidth and throughput are limited
has a very large roster which cause connections to take an unacceptable has a very large roster which cause connecting to take an unacceptable
amount of time. With entity versioning, connections after the first amount of time.
connection do not take as long, and use less bandwidth. With entity versioning, subsequent connections after the first do not
take as long, and use less bandwidth.
</li> </li>
<li> <li>
A client often wants to view the list of multi-user chat rooms A client often wants to view the list of multi-user chat rooms
@ -238,21 +241,22 @@
</p> </p>
<p> <p>
Servers that implement this protocol must assign such a version token to Servers that implement this protocol must assign such a version token to
each entity that is controlled by the server. The server SHOULD then each entity that is controlled by the server.
update this version every time any mutable property of the entity changes The server SHOULD then update this version every time any mutable property
(eg. when the subscription status of a user changes). The server MAY of the entity changes (eg. when the subscription status of a user
choose to update this token at any time (to force the clients to changes).
invalidate their cached representation fo the object). This version token The server MAY choose to update this token at any time (to force the
MUST then be included with every object representation of that entity clients to invalidate their cached representation of the object).
sent down in the stream. This is done by including a sub-node called This version token MUST then be included with every object representation
"version" qualified by the entity versioning XML namespace defined in of that entity transmitted in the stream.
this document. Similarly, clients MAY also add version nodes for each This is done by including a sub-node called "version" qualified by the
version token they possess to the request for a list (not specifying a entity versioning XML namespace defined in this document.
version token will force the server to send information on that entity to Similarly, clients MAY also add version nodes for each version token they
the client). If a client sends up a list of version tokens, the server possess to the request for a list (not specifying a version token will
MUST then check to see if those tokens correspond to any entity which it force the server to send information on that entity to the client).
knows about, and not send down any entities with matching version tokens If a client sends up a list of version tokens, the server MUST then check
in the response. 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.
</p> </p>
<p> <p>
For example, a versioned roster request might look like this: For example, a versioned roster request might look like this: