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

xep-0366.xml

@@ -26,10 +26,12 @@
   <supersededby />
   <shortname>EV</shortname>
   &sam;
-  <author>
-    <firstname>Doug</firstname>
-    <surname>Keen</surname>
-  </author>
+  <revision>
+    <version>0.1.2</version>
+    <date>2016-12-21</date>
+    <initials>ssw</initials>
+    <remark><p>Spelling, tone, and grammar.</p></remark>
+  </revision>
   <revision>
     <version>0.1.1</version>
     <date>2016-07-11</date>
@@ -59,17 +61,17 @@
 <section1 topic='Introduction' anchor='intro'>
   <p>
     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.
   </p>
 </section1>
 
@@ -79,7 +81,7 @@
       An extra round trip MUST NOT be required to initiate entity versioning.
     </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.
     </li>
     <li>
@@ -124,9 +126,10 @@
     <ul>
       <li>
         A client on a mobile device where bandwidth and throughput are limited
-        has a very large roster which cause connections to take an unacceptable
-        amount of time. With entity versioning, connections after the first
-        connection do not take as long, and use less bandwidth.
+        has a very large roster which cause connecting to take an unacceptable
+        amount of time.
+        With entity versioning, subsequent connections after the first do not
+        take as long, and use less bandwidth.
       </li>
       <li>
         A client often wants to view the list of multi-user chat rooms
@@ -238,21 +241,22 @@
     </p>
     <p>
       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.
     </p>
     <p>
       For example, a versioned roster request might look like this: