1.5

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@225 4b5297f7-1745-476d-ba37-a9c6900126ab

xep-0016.xml

@@ -23,9 +23,9 @@
   &stpeter;
   <revision>
     <version>1.5</version>
-    <date>2006-11-21</date>
+    <date>2006-11-27</date>
     <initials>psa</initials>
-    <remark><p>In order to track XEP-0191, specified that server should not ignore messages from blocked entities but instead should return a &lt;service-unavailable/&gt; error.</p></remark>
+    <remark><p>Modified message stanza handling (server should return &lt;service-unavailable/&gt; error) and added implementation note to maintain consistency with XEP-0191. error.</p></remark>
   </revision>
   <revision>
     <version>1.4</version>
@@ -85,10 +85,10 @@
 <section1 topic="Introduction">
   <p>Almost all types of Instant Messaging (IM) applications have found it necessary to develop some method for a user to block the receipt of messages and packets from other users (the rationale for such blockage depends on the needs of the individual user). This document defines a flexible method for communications blocking.</p>
   <p>Note: The protocol specified herein MAY be used in conjunction with &xep0191;; see <cite>XEP-0191</cite> for details.</p>
-  <p><em>The remainder of this document has been copied without modification from Section 10 of &rfc3921;.</em></p>
 </section1>
 
 <section1 topic="Protocol" anchor="protocol">
+  <p><em>This section has been copied without modification from Section 10 of &rfc3921;, with the exception of the message stanza handling rule in the <link url='#protocol-error'>Blocked Entity Attempts to Communicate with User</link> subsection.</em></p>
   <p>Most instant messaging systems have found it necessary to implement some method for users to block communications from particular other users (this is also required by sections 5.1.5, 5.1.15, 5.3.2, and 5.4.10 of &rfc2779;.  In XMPP this is done by managing one's privacy lists using the 'jabber:iq:privacy' namespace.</p>
   <p>Server-side privacy lists enable successful completion of the following use cases:</p>
   <ul>
@@ -735,7 +735,7 @@
     <p>If a blocked entity attempts to send a stanza to the user (i.e., an inbound stanza from the user's perspective), the user's server shall handle the stanza according to the following rules:</p>
     <ul>
       <li>For presence stanzas (including notifications, subscriptions, and probes), the server MUST NOT respond and MUST NOT return an error.</li>
-      <li>For message stanzas, the server SHOULD return an error, which SHOULD be &unavailable;.</li>
+      <li>For message stanzas, the server SHOULD return an error, which SHOULD be &unavailable;. <note>Until version 1.5 of this document (therefore also in <cite>RFC 3921</cite>), it was recommended to silently ignore message stanzas, which unfortunately resulted in a delivery "black hole" regarding message stanzas.</note></li>
       <li>For IQ stanzas of type "get" or "set", the server MUST return an error, which SHOULD be &unavailable;. IQ stanzas of other types MUST be silently dropped by the server.</li>
     </ul>
     <p>If the foregoing suggestions are followed, the user will appear offline to the contact.</p>
@@ -785,6 +785,22 @@
   </section2>
 </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>
+</section1>
+<section1 topic='Security Considerations' anchor='security'>
+  <p>If properly implemented, this protocol extension does not introduce any new security concerns above and beyond those defined in <cite>RFC 3920</cite> and <cite>RFC 3921</cite>.</p>
+</section1>
+<section1 topic='IANA Considerations' anchor='iana'>
+  <p>No interaction with &IANA; is required as a result of this specification.</p>
+</section1>
+<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
+  <section2 topic='Protocol Namespaces' anchor='registrar-ns'>
+    <p>The &REGISTRAR; already includes 'jabber:iq:privacy' in its registry of protocol namespaces (see &NAMESPACES;).</p>
+  </section2>
+</section1>
+
 <section1 topic="XML Schema" anchor="schema">
   <code><![CDATA[
 <?xml version='1.0' encoding='UTF-8'?>