Allow eliding of <unread> in XEP-0386

xep-0386.xml

@@ -10,7 +10,7 @@
   <abstract>This specification provides a single-request replacement for several activities an XMPP client needs to do at startup.</abstract>
   &LEGALNOTICE;
   <number>0386</number>
-  <status>Deferred</status>
+  <status>Experimental</status>
   <type>Standards Track</type>
   <sig>Standards</sig>
   <approver>Council</approver>
@@ -24,6 +24,12 @@
   <supersededby/>
   <shortname>bind2</shortname>
   &ksmithisode;
+  <revision>
+    <version>0.3.0</version>
+    <date>2019-01-31</date>
+    <initials>kis</initials>
+    <remark>Begrudingly allow non-unread-tracking servers, mention SASL2.</remark>
+  </revision>
   <revision>
     <version>0.2.0</version>
     <date>2018-02-08</date>
@@ -39,7 +45,7 @@
 </header>
 <section1 topic='Introduction' anchor='intro'>
   <p>As XMPP has grown more feature-rich over time, more steps have been introduced that clients are likely to perform at startup, e.g. resource binding, archive synchronisation, enabling Carbons. Some of these introduce race conditions - e.g. if a client synchronises the archive before enabling Carbons, it can miss stanzas sent between these events, or if it enables Carbons before synchronising the archive it can receive duplicate messages. It may also cause duplicate messages by combining archive synchronisation and receipt of offline messages, or by receipt of messages addressed to the full JID between resource binding and archive synchronisation. This document provides a mechanism for atomically performing these operations to avoid these race conditions. It also provides information to a client that is generally useful about the state of the archive.</p>
-  <p>There have been other (not-yet documented) suggestions of further enhancements to the stream startup process, and it is possible that in the future some protocol here may be reframed in terms of such new facilities, but the core premise of the XEP (that these features are needed, and need enabling together) remains. It may be desirable to make the enabling of features extensible, such that the client can request which features are needed, together, but the current approach should serve as a suitable basis for discussion.</p>
+  <p>There have been other suggestions of further enhancements to the stream startup process in XEP-0388 (SASL2), and it is expected that in the future some protocol here will be reframed in terms of these facilities, but the core premise of the XEP (that these features are needed, and need enabling together) remains. It may be desirable to make the enabling of features extensible, such that the client can request which features are needed, together, but the current approach should serve as a suitable basis for discussion.</p>
   <p>The returning of unread message state to the client relies on the archive having these data, which is a topic for another specification.</p>
 </section1>
 <section1 topic='Requirements' anchor='reqs'>
@@ -52,7 +58,7 @@
 </section1>
 <section1 topic='Use Cases' anchor='usecases'>
   <section2 topic='Discovering support'>
-    <p>A client does not advertise support for bind 2.0. If a server supports bind 2.0, it MUST advertise this in the stream features with an feature named 'bind' in the namespace 'urn:xmpp:bind2:0'.</p>
+    <p>A client does not advertise support for bind 2.0. If a server supports bind 2.0, it MUST advertise this in the stream features with a feature named 'bind' in the namespace 'urn:xmpp:bind2:0'.</p>
     <example caption='Server advertises support in stream features'><![CDATA[
 <stream:features>
   <bind xmlns='urn:xmpp:bind2:0'/>
@@ -86,6 +92,7 @@
   </unreads>
 </bound>
 ]]></example>
+    <p>Servers SHOULD support the &lt;unreads> feature, but if they do not then the &lt;unreads> element MUST be elided, to distinguish between an empty element (no unread messages) and a missing feature.</p>
   </section2>
 
   <section2 topic='Pipelining'>