<remark><p>Specified relationship to privacy lists, JID matching rules, server handling of outbound presence on block and unblock, handling of directed presence, syntax of block element.</p></remark>
<remark><p>Added implementation notes regarding polite blocking and filtering of search results; recommended retrieval of block list after authentication; defined protocol flow for unblocking all contacts.</p></remark>
<p>&rfc3921; includes an XMPP protocol extension for communications blocking, which has since been moved to &xep0016;. Unfortunately, because the privacy lists extension is quite complex, it has not been widely implemented in servers and has been implemented virtually not at all in clients. This is problematic, since the ability to block communications with selected users is an important feature for an instant messaging system (and is required by &rfc2779;). However, the full power of privacy lists is not needed in order to block communications, so this document proposes a simpler blocking protocol that meets the requirement specified in <cite>RFC 2779</cite> and can be implemented more easily in XMPP clients and servers.</p>
<p>In order for a client to discover whether its server supports the protocol defined herein, it MUST send a &xep0030; information request to the server:</p>
<p>In order for a client to request a user's list of blocked JIDs (e.g., in order to determine whether to unblock a JID), it shall send an IQ-get with no 'to' address (thus handled by the user's server) containing a <blocklist/> element qualified by the 'urn:xmpp:blocking' namespace:</p>
<p>If the user has any JIDs in its blocklist, the server MUST return an IQ-result containing a <blocklist/> element that in turn contains one child <item/> element for each blocked JID:</p>
<p>In order for a user to block communications with a JID, the user's client shall send an IQ-set with no 'to' address (thus handled by the user's server) containing a <block/> element qualified by the 'urn:xmpp:blocking' namespace, where the JID to be blocked is encapsulated as the 'jid' attribute of the <item/> child element:</p>
<p>If the <block/> element does not contain at least one <item/> child element, the server MUST return a &badrequest; error. The <block/> element MAY contain more than one <item/> child. Other standard XMPP stanza errors also apply; see &xmppcore; and &xep0086;.</p>
<p>When the user blocks communications with a JID, the user's server MUST send unavailable presence information to the JID (but only if the JID is allowed to receive presence notifications from the user in accordance with the rules defined in <cite>RFC 3921</cite>).</p>
<p>Once the user has blocked communications with a JID, the user's server MUST NOT deliver any XML stanzas from the JID to the user. The block remains in force until the user subsequently unblocks commmunications with the JID (i.e., the duration of the block is potentially unlimited and applies across sessions).</p>
<p>If a blocked JID 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>
<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>
<p>If the foregoing suggestions are followed, the user will appear offline to the blocked JID.</p>
<p>If the user attempts to send an outbound stanza to the JID, the user's server MUST NOT route the stanza to the JID but instead MUST return a ¬acceptable; error containing an application-specific error condition of <blocked/> qualified by the 'urn:xmpp:blocking:errors' namespace:</p>
<p>In order for a user to unblock communications with a JID, the user's client shall send an IQ-set with no 'to' address (thus handled by the user's server) containing an <unblock/> element qualified by the 'urn:xmpp:blocking' namespace, where the JID to be unblocked is encapsulated as the 'jid' attribute of the <item/> child element:</p>
<p>When the user unblocks communications with a JID, the user's server MUST send the user's current presence information to the JID (but only if the JID is allowed to receive presence notifications from the user in accordance with the rules defined in <cite>RFC 3921</cite>).</p>
<p>After the user has unblocked communications with a JID, the user's server MUST deliver any subsequent XML stanzas from the JID to the user.</p>
<section2topic='User Unblocks All blocked JIDs'anchor='unblockall'>
<p>In order for a user to unblock communications with all JIDs, the user's client shall send an IQ-set with no 'to' address (thus handled by the user's server) containing an empty <unblock/> element qualified by the 'urn:xmpp:blocking' namespace:</p>
<p>The server MUST also send an IQ-set to all of the user's resources that have requested the blocklist, containing notification of global unblocking:</p>
<examplecaption='Unblock all "push"'><