Merge branch 'feature/xep-0436'

xep-0436.xml

@@ -24,6 +24,20 @@
   <shortname>omnipresent-muc-affiliates</shortname>
   &jcbrand;
   &mwild;
+  <revision>
+    <version>0.2.0</version>
+    <date>2020-05-10</date>
+    <initials>jcb</initials>
+    <remark>
+        <p>Incorporate feedback from the standards list</p>
+        <ul>
+            <li>Create a separate tag for sending the version number.</li>
+            <li>Include a reset token.</li>
+            <li>Remove the "Additional measures" section and merge parts into "Requirements".</li>
+            <li>Mandate that presences are always sent for affiliated users.</li>
+        </ul>
+    </remark>
+  </revision>
   <revision>
     <version>0.1.0</version>
     <date>2020-05-05</date>
@@ -48,47 +62,48 @@
         The notion of "room presence" is therefore less relevant than before, and in some cases can be done away with entirely.
     </p>
     <p>
-        Broadcasting all XEP-0045 MUC participants' presences to one another scales quadratically (O(n^2)) and can greatly increase the amount of network traffic, for potentially negligable gain.
+        Broadcasting all XEP-0045 MUC participants' presences to one another scales quadratically (O(n^2)) and can greatly increase the amount of network traffic,
+        for potentially negligable gain.
     </p>
     <p>
         Even though the metaphorical concept of presence inside a room might no longer be relevant for a groupchat implementation,
-        &lt;presence/&gt; stanzas might still contain useful metadata, such as the user's affiliation or their &xep0317;.
+        &lt;presence/&gt; stanzas might still contain useful metadata, such as the user's affiliation or &xep0317;.
     </p>
     <p>
         This XEP defines a versioning mechanism (similar to roster versioning in &rfc6121;) whereby the amount of presence traffic in a MUC may be greatly reduced.
-        It also describes additional measures which may be taken to further reduce the amount of presence traffic.
     </p>
 </section1>
 
 <section1 topic="How it works">
     <p>
-        A client that supports presence versioning needs to keep track and store the presence statuses of all MUC occupants, across multiple MUC sessions.
+        A client that supports MUC presence versioning needs to keep track and store the presence states of all MUC occupants, across multiple MUC sessions.
-        Similarly, a MUC service which supports presence versioning will also need to maintain a changelog of version numbers and presence states.
+        Similarly, a MUC service which supports presence versioning will also need to maintain a changelog of version numbers and corresponding presence states.
     </p>
     <p>
         Before the client enters a MUC, it SHOULD use service discovery to check whether presence versioning is supported
         (see <link url="#disco">determining support</link> below.).
-        If presence versioning is supported, the client MAY include a 'ver' attribute set to the last known presence version
+        If MUC presence versioning is supported, the client MAY include a &lt;version&gt; tag with a 'ver' attribute set to the last known version
-        in the &lt;{http://jabber.org/protocol/muc}x&gt; tag of the &lt;presence/&gt; stanza, which it sends to join the MUC.
+        inside the &lt;{http://jabber.org/protocol/muc#user}x&gt; tag of the &lt;presence/&gt; stanza, which it sends to join the MUC.
-    </p>
-    <p>
-        If presence versioning is not supported by the server, the client MUST NOT include a 'ver' attribute.
     </p>
     <p>
+        If MUC presence versioning is not supported by the server, the client MUST NOT include a 'ver' attribute.
     </p>
 
-    <example caption='User specifies the last known presence version when seeking to enter a MUC'><![CDATA[
+    <example caption='User specifies the last known version when seeking to enter a MUC'><![CDATA[
 <presence
     from='hag66@shakespeare.lit/pda'
     id='n13mt3l'
     to='coven@chat.shakespeare.lit/thirdwitch'>
-  <x xmlns='http://jabber.org/protocol/muc' ver='ver14'/>
+  <x xmlns='http://jabber.org/protocol/muc#user'>
+    <version xmlns='urn:xmpp:muc-presence-versioning:0' ver='ver16' />
+  </x>
 </presence>
 ]]></example>
 
     <p>
         The MUC will return only those presences that have changed since the version indicated by the client, and in the self-presence of the joining user it will add a
-        'ver' attribute with the latest version number on the &lt;{http://jabber.org/protocol/muc}x&gt; tag. The client must save the version number and use it next time it joins the MUC.
+        &lt;version&gt; tag with a 'ver' attribute set to the latest version number inside the &lt;{http://jabber.org/protocol/muc#user}x&gt; tag.
+        The client must save the version number (and continuously update with never versions as they're received) and use that next time it joins the MUC.
     </p>
 
     <example caption="Service Sends New Occupant's Presence to New Occupant"><![CDATA[
@@ -96,7 +111,8 @@
     from='coven@chat.shakespeare.lit/thirdwitch'
     id='n13mt3l'
     to='hag66@shakespeare.lit/pda'>
-  <x xmlns='http://jabber.org/protocol/muc#user' ver='ver16'>
+  <x xmlns='http://jabber.org/protocol/muc#user'>
+    <version xmlns='urn:xmpp:muc-presence-versioning:0' ver='ver17' />
     <item affiliation='member' role='participant'/>
     <status code='110'/>
   </x>
@@ -104,12 +120,14 @@
 ]]></example>
 
     <p>
-        When presence versioning is enabled, every subsequent &lt;presence/&gt; stanza sent by the server MUST include a new version number, which replaces the existing one saved by the client.
+        When presence versioning is enabled, every subsequent &lt;presence/&gt; stanza sent by the server MUST include a new version number,
+        which replaces the existing one saved by the client.
     </p>
 </section1>
 
 <section1 topic='Determining support' anchor='disco'>
-    <p>If a MUC implements presence versioning, it MUST specify the 'urn:xmpp:muc-presence-versioning:0' feature in its service discovery information features, as specified in &xep0030;.</p>
+    <p>If a MUC implements presence versioning, it MUST specify the 'urn:xmpp:muc-presence-versioning:0' feature in its service discovery information features,
+        as specified in &xep0030;.</p>
 <example caption='Client queries for information about a specific MUC'><![CDATA[
     <iq type='get'
         from='romeo@montague.example/orchard'
@@ -125,57 +143,74 @@
         id='info1'>
     <query xmlns='http://jabber.org/protocol/disco#info'>
     ...
-        <feature var='urn:xmpp:presence-versioning:0'/>
+        <feature var='urn:xmpp:muc-presence-versioning:0'/>
     ...
     </query>
     </iq>]]></example>
 </section1>
 
+<section1 topic='Requirements' anchor='requirements'>
+    <section2 topic='Always broadcast presence for affiliated users' anchor='affiliate-presence'>
+        <p>
+            A MUC that supports presence versioning MUST broadcast presence for all affiliated users, including those who are currently 'unavailable'.
+            <cite>XEP-0045</cite> documents the status code '102', which is used to indicate that a MUC shows unavailable members.
+        </p>
+        <p>
+            The only exception is when a MUC has been explicitly configured to only broadcast presence from occupants above a certain affiliation,
+            (see the <link url='https://xmpp.org/extensions/xep-0045.html#enter-pres'>presence broadcast</link> section of <cite>XEP-0045</cite>).
+        </p>
+        <p>
+            In order for a user to permanently join a room, and therefore become affiliated so that they are included in presence broadcasts,
+            they MAY be allowed to register themselves as members in the MUC.
+            <cite>XEP-0045</cite> describes in <link url='https://xmpp.org/extensions/xep-0045.html#register'>section 7.10 "Registering with a Room</link>
+            how a user may register themselves with a room, thereby receiving the "member" affiliation and having their preferred nickname reserved in that room.
+        </p>
+    </section2>
+
+    <section2 topic="Include a reset token when the client's version number has expired" anchor='reset-token'>
+        <p>
+            If a MUC receives a presence version number that's so old, that it no longer has the corresponding state available,
+            it MUST include a &lt;reset&gt; token in the first &lt;presence&gt; stanza it sends (regardless of whom in the MUC the presence relates to).
+            The first presence stanza MAY be from the MUC itself (as shown in the example below).
+            Afterwards, the MUC MUST then send all presences (including 'unavailable' for affiliated users) as if the client is starting from a blank slate.
+        </p>
+
+    <example caption="Service Sends a Reset Token"><![CDATA[
+<presence from='coven@chat.shakespeare.lit'
+          id='r3s3t-m3'
+          to='hag66@shakespeare.lit/pda'>
+    <x xmlns='http://jabber.org/protocol/muc#user'>
+        <reset xmlns='urn:xmpp:muc-presence-versioning:0' ver='ver36' />
+    </x>
+</presence>
+]]></example>
+    </section2>
+</section1>
+
 <section1 topic='Business Rules' anchor='rules'>
-    <p>If a MUC receives a presence version number that's so old, so that it no longer has the corresponding state available, it needs to send all presence statuses back to the client.</p>
+    <p>
+        Even if the client did not include a &lt;version&gt; tag with a 'ver' attribute in its "join" &lt;presence/&gt; stanza,
+        the server SHOULD still return a &lt;version&gt; tag with 'ver' attribute (set to the latest version number)
+        on all relevant &lt;presence/&gt; stanzas.
+        This allows clients to bootstrap MUC presence versioning without having to do a service discovery query first.
+    </p>
     <p>
         If the client has not yet saved a presence version number and the corresponding presence states,
         then it MUST bootstrap presence versioning by sending a 'ver' attribute set to the empty string (i.e., ver="").
     </p>
+
     <p>
-        Even if the client did not include a 'ver' attribute in its "join" &lt;presence/&gt; stanza, the server SHOULD still set a 'ver' attribute on the relevant &lt;presence/&gt; stanzas.
+        In some cases, the presence states being kept track of by the MUC service MAY be reduced to a minimum of only two states, 'available' and 'unavailable'.
+        This can drastically reduce the number of states the server needs to keep track off, at the cost of not allowing users to provide more fine-grained
+        reporting of their level of availability.
     </p>
 </section1>
 
-<section1 topic="Additional measures">
+<section1 topic="Security Considerations">
     <p>
-        There are a number of &xep0045; features that a client and server may decide to configure and/or implement in order to further reduce the number of presence stanzas being sent around.
+        The MUC service should strip the &lt;version&gt; tag from the user's &lt;presence&gt; before relaying it to other occupants,
+        to avoid leaking information on when last the user joined the MUC.
     </p>
-
-
-    <section2 topic='Only broadcast presence for affiliated users' anchor='affiliate-presence'>
-        <p>
-            A MUC MAY be configured to only broadcast presence from occupants above a certain affiliation,
-            (see the <link url='https://xmpp.org/extensions/xep-0045.html#enter-pres'>presence broadcast</link> section of <cite>XEP-0045</cite>),
-            for example in a MUC where non-affiliated users are allowed to view the discussion but aren't allowed to send messages.
-        </p>
-        <section3 topic="Let users register themselves with a MUC">
-            <p>
-                This step can be taken in addition to letting users register themselves as members in the MUC.
-                XEP-45 describes in <link url='https://xmpp.org/extensions/xep-0045.html#register'>section 7.10 "Registering with a Room</link> how a user may register themselves with a room,
-                thereby receiving the "member" affiliation and having their preferred nickname reserved in that room.
-            </p>
-        </section3>
-    </section2>
-
-    <section2 topic='Restrict presence states to available and unavailable' anchor='restrict-states'>
-        <p>
-            In some cases, it makes sense to reduce the number of presence statuses to only a subset, in order to reduce to total amount of states the server needs to keep track off.
-            In the simplest case, this would mean keeping track only of two statuses, 'available' and 'unavailable'.
-        </p>
-        <section3 topic='Send presence stanzas for unavailable members' anchor='send-unavailable-presence'>
-            <p>
-                XEP-0045 documents the status code 102, which is used to indicate that a room shows unavailable members.
-                By also sending to newly joined users the presence stanzas of unavailable members,
-                it's possible to provide any necessary presence metadata of all relevant users in a groupchat and not just the currently "present" users.
-            </p>
-        </section3>
-    </section2>
 </section1>
 
 <section1 topic='IANA Considerations' anchor='iana'>