From b3725e2cf9070cd750bd025bea46da13e433a403 Mon Sep 17 00:00:00 2001
From: Sam Whited <sam@samwhited.com>
Date: Thu, 27 Aug 2015 16:22:55 -0500
Subject: [PATCH] Add a use case to entity versioning

Also:

  Minor typo and wording fixes
  Fix broken example XML
  More tabbing fixes
---
 inbox/entityversioning.xml | 36 ++++++++++++++++++++----------------
 1 file changed, 20 insertions(+), 16 deletions(-)

diff --git a/inbox/entityversioning.xml b/inbox/entityversioning.xml
index 16dec0d4..45451591 100644
--- a/inbox/entityversioning.xml
+++ b/inbox/entityversioning.xml
@@ -50,12 +50,11 @@
     This problem of "downloading the world" (downloading the entire roster
     every time a session is initialized) 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 (eg.  MUC
-    disco#items). Furthermore, roster versioning requires that the server
-    maintain a great deal of state (multiple versions of the roster) which can
-    be difficult to implement in a large, distributed system. This XEP defines
-    a method by which entities other than the roster can be versioned and
-    cached.
+    for the roster, it didn't account for other entities (eg. disco items).
+    Furthermore, roster versioning requires that the server maintain a great
+    deal of state (multiple versions of the roster) which can be difficult to
+    implement in a large, distributed system. This XEP defines a method by
+    which entities other than the roster can be versioned and cached.
   </p>
 </section1>
 
@@ -115,6 +114,11 @@
         client can fetch the list, and then poll for changes at a later date
         without re-requesting the entire list.
       </li>
+      <li>
+        A client wishes to cache the features supported by servers of the
+        contacts in their roster since their disco items is not likely to
+        change often.
+      </li>
     </ul>
   </section2>
   <section2 topic='Servers' anchor='server_use_cases'>
@@ -200,11 +204,11 @@
 
 <!-- Server -->
 <iq from='romeo@montague.lit' id='56' to='romeo@montague.lit/home' type='result>
-    <query xmlns='jabber:iq:roster'>
-      <item subscription='both' jid='bill@shakespeare.lit' />
+  <query xmlns='jabber:iq:roster'>
+    <item subscription='both' jid='bill@shakespeare.lit'>
       <version xmlns='urn:xmpp:entityver:0'>9ZFZXVP9</version>
-      </item>
-    </query>
+    </item>
+  </query>
 </iq>
     ]]></example>
     <p>
@@ -218,7 +222,7 @@
 <!-- Server -->
 <iq from='romeo@montague.lit' id='ah382g678jka7' to='romeo@montague.lit/home' type='set'>
     <query xmlns='jabber:iq:roster' ver='ver34'>
-      <item jid='tybalt@shakespeare.lit' subscription='remove>
+      <item jid='tybalt@shakespeare.lit' subscription='remove'>
         <version xmlns='urn:xmpp:entityver:0'>XWE4MUUP</version>
       </item>
     </query>
@@ -243,13 +247,13 @@
 
 <!-- Server -->
 <iq from='chat.shakespeare.lit'
-    id='zb8q41fas6yn4'
-    to='hag66@shakespeare.lit/phone'
-    type='result'>
+  id='zb8q41fas6yn4'
+  to='hag66@shakespeare.lit/phone'
+  type='result'>
   <query xmlns='http://jabber.org/protocol/disco#items'>
     <item jid='coven@chat.shakespeare.lit'
           name='A Dark Cave'>
-        <version xmlns='urn:xmpp:entityver:0'>VIZSVF0D</version>
+      <version xmlns='urn:xmpp:entityver:0'>VIZSVF0D</version>
     </item>
   </query>
 </iq>
@@ -346,7 +350,7 @@ anne@shakespeare.lit:VIZSVF0D,bill@shakespeare.lit:25P2A7H8
   </p>
   <p>
     Version tokens SHOULD always be considered opaque to the client (eg. even
-    if the version token is a derivable and consistant hash on the server side,
+    if the version token is a derivable and consistent hash on the server side,
     clients should not need to know how the server is calculating the token).
   </p>
   <p>