SPEC-17

xep-0016.xml

@@ -802,6 +802,30 @@
   </section2>
 </section1>
 
+<section1 topic='Discovering Support' anchor='disco'>
+  <p>If an entity supports the privacy lists protocol, it MUST report that fact by including a service discovery feature of "jabber:iq:privacy" &NSNOTE; in response to a &xep0030; information request:</p>
+  <example caption="Service Discovery information request"><![CDATA[
+<iq from='juliet@example.com/chamber'
+    id='disco1'
+    to='example.com'
+    type='get'>
+  <query xmlns='http://jabber.org/protocol/disco#info'/>
+</iq>
+  ]]></example>
+  <example caption="Service Discovery information response"><![CDATA[
+<iq from='example.com'
+    id='disco1'
+    to='juliet@example.com/chamber'
+    type='result'>
+  <query xmlns='http://jabber.org/protocol/disco#info'>
+    ...
+    <feature var='jabber:iq:privacy'/>
+    ...
+  </query>
+</iq>
+  ]]></example>
+</section1>
+
 <section1 topic='Implementation Notes' anchor='impl'>
   <p>When a server receives a block command from a user, it MAY cancel any existing presence subscriptions between the user and the blocked user and MAY send a message to the blocked user; however, it is RECOMMENDED to deploy so-called "polite blocking" instead (i.e., to not cancel the presence subscriptions or send a notification). Which approach to follow is a matter of local service policy.</p>
   <p>A service MAY also filter blocking users out of searches performed on user directories (see, for example, &xep0055;); however, that functionality is out of scope for this specification.</p>