XEP-0186: Address LC feedback

xep-0186.xml

@@ -11,7 +11,7 @@
   &LEGALNOTICE;
   <number>0186</number>
   <status>Proposed</status>
-  <lastcall>2017-03-14</lastcall>
+  <lastcall>2017-12-12</lastcall>
   <type>Standards Track</type>
   <sig>Standards</sig>
   <dependencies>
@@ -25,11 +25,17 @@
   <supersededby/>
   <shortname>invisible</shortname>
   &stpeter;
+  <revision>
+    <version>0.13</version>
+    <date>2017-11-29</date>
+    <initials>psa</initials>
+    <remark><p>Addressed Last Call feedback: (1) clarified conformance requirements for 'probe' attribute and (2) removed text about using the same server backend for privacy lists because XEP-0016 is now deprecated.</p></remark>
+  </revision>
   <revision>
     <version>0.12</version>
     <date>2017-01-28</date>
     <initials>psa</initials>
-    <remark><p>Added method for specifying server behavior regarding presence probes via new 'probe' attribute; increased the protocol version number from 0 to 1.</p></remark>
+    <remark><p>Added method for specifying server behavior regarding presence probes via new 'probe' attribute; incremented the protocol version number from 0 to 1.</p></remark>
   </revision>
   <revision>
     <version>0.11</version>
@@ -112,12 +118,7 @@
 </header>
 
 <section1 topic='Introduction' anchor='intro'>
-  <p>Some XMPP-based instant messaging systems have long supported the ability for users to be online but to appear offline to other users. The existing protocols for this "invisibility" feature are:</p>
+  <p>Some XMPP-based instant messaging systems have long supported the ability for users to be online but to appear offline to other users. This "invisibility" feature was previously defined in nonstandard or complicated ways via &xep0018; and &xep0126; (the latter was a profile of &xep0016;, which is now deprected). By contrast, this specification defines a standards-compliant protocol extension that can be used over the long term, using an IQ-based protocol that enables an IM user to become "invisible" and "visible" at will within the context of a given session.</p>
-  <ul>
-    <li><p>&xep0018; -- this protocol is not compatible with &xmppcore; and &xmppim; because it defines new values of the 'type' attribute for the &PRESENCE; outside of the IETF (also, the specification does not provide reliable documentation of the protocol in use, since many server implementations support presence of type "invisible" but not presence of type "visible").</p></li>
-    <li><p>&xep0126; -- this protocol is a somewhat complicated profile of &xep0016; to enable temporary invisibility, and violates the spirit of XEP-0016, which was defined to enable permanent blocking of communications instead of per-session interactions (nevertheless, the invisible command defined here can provide a client-friendly interface to the same data backend used for privacy lists).</p></li>
-  </ul>
-  <p>In order to provide a standards-compliant protocol extension that can be used in the long term, this document defines an IQ-based protocol that enables an IM user to become "invisible" and "visible" at will within the context of a given session.</p>
 </section1>
 
 <section1 topic='Requirements' anchor='req'>
@@ -132,7 +133,7 @@
 <section1 topic='Use Cases' anchor='usecases'>
   <section2 topic='User Becomes Invisible' anchor='invisible'>
     <p>In order for a client to go invisible, it sends an IQ-set with no 'to' address (thus handled by the user's server) containing an &lt;invisible/&gt; element qualified by the 'urn:xmpp:invisible:1' namespace &VNOTE;.</p>
-    <p>The &lt;invisible/&gt; element MUST include a 'probe' attribute, which specifies whether the server shall or shall not send presence probes to entities in the user's roster (thus determining whether the user does or does not automatically receive presence notifications from contacts). This attribute is a boolean &BOOLEANNOTE;, where a logical value of TRUE (lexical value of "true" or "1") indicates that the server shall send presence probes and where a logical value of FALSE (lexical value of "false" or "0") indicates that the server shall not send presence probes. The default logical value is FALSE.</p>
+    <p>The &lt;invisible/&gt; element SHOULD include a 'probe' attribute, which specifies whether the server shall or shall not send presence probes to entities in the user's roster (thus determining whether the user does or does not automatically receive presence notifications from contacts). This attribute is a boolean &BOOLEANNOTE;, where a logical value of TRUE (lexical value of "true" or "1") indicates that the server shall send presence probes and where a logical value of FALSE (lexical value of "false" or "0") indicates that the server shall not send presence probes. The default logical value is FALSE.</p>
     <example caption='Invisible command with indication to send presence probes'><![CDATA[
 <iq from='bilbo@tolkien.example/shire'
     id='d1s4pp34r1'
@@ -234,8 +235,8 @@
   <p>A client SHOULD complete this service discovery process before sending initial presence to its server (as specified in &xep0115;, a server can include entity capabilities information in a stream feature, which obviates the need for explicit service discovery as shown above).</p>
 </section1>
 
-<section1 topic='Integration With Privacy Lists' anchor='priv'>
+<section1 topic='Interoperability Considerations' anchor='interop'>
-  <p>A server MAY use the same data backend for this invisibility mode as for privacy lists when employed for invisibility (see <cite>XEP-0126</cite>). If so, the server MUST update the relevant privacy lists on behalf of the user when the client sends an invisible command or a visible command as specified herein.</p>
+  <p>Implementers need to be aware that use of the 'probe' attribute is not consistent with the older privacy lists approach defined in XEP-0126.</p>
 </section1>
 
 <section1 topic='Security Considerations' anchor='security'>
@@ -295,7 +296,7 @@
 </section1>
 
 <section1 topic='Acknowledgements' anchor='ack'>
-  <p>Thanks to Philipp Hancke, Kevin Smith, Matthew Wild and Ruslan N. Marchenko for their feedback.</p>
+  <p>Thanks to Philipp Hancke, Evgeny Khramtsov, Ruslan Marchenko, Kevin Smith, and Matthew Wild for their feedback.</p>
 </section1>
 
 </xep>