XEP-0191: Simple Communications Blocking

Peter Saint-Andre

Email: stpeter@jabber.org
JID: stpeter@jabber.org

1. Introduction

2. Requirements

3. Relationship to Privacy Lists

4. JID Matching

5. Use Cases

5.1. User Discovers Support

5.2. User Retrieves Block List

5.3. User Blocks Contact

5.4. User Unblocks Contact

5.5. User Unblocks All Contacts

6. Implementation Notes

7. Security Considerations

8. IANA Considerations

9. XMPP Registrar Considerations

9.1. Protocol Namespaces

10. XML Schema

10.1. blocking

10.2. blocking#errors

11. Acknowledgements

Notes

Revision History

5.1 User Discovers Support

In order for a client to discover whether its server supports the protocol defined herein, it MUST send a Service Discovery [4] information request to the server:

Example 1. Service discovery request

<iq from='juliet@capulet.com/chamber' to='capulet.com' type='get' id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
    

If the server supports the protocol defined herein, it MUST return a feature of "http://jabber.org/protocol/blocking":

Example 2. Service discovery response

<iq from='capulet.com' to='juliet@capulet.com/chamber' type='result' id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='http://jabber.org/protocol/blocking'/>
    ...
  </query>
</iq>
    

5.2 User Retrieves Block List

In order for a client to request a user's list of blocked contacts (e.g., in order to determine whether to unblock a contact), it shall send an IQ-get with no 'to' address (thus handled by the user's server) containing a <blocklist/> element qualified by the 'http://jabber.org/protocol/blocking' namespace:

Example 3. Client requests blocklist

<iq type='get' id='blocklist1'>
  <blocklist xmlns='http://jabber.org/protocol/blocking'/>
</iq>
    

If the user has any contacts 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 contact:

Example 4. Server returns blocklist with items

<iq type='result' id='blocklist1'>
  <blocklist xmlns='http://jabber.org/protocol/blocking'>
    <item jid='romeo@montague.net'/>
    <item jid='iago@shakespeare.lit'/>
  </blocklist>
</iq>
    

If the user has no contacts in its blocklist, the server MUST return an IQ-result containing an empty <blocklist/> element:

Example 5. Server returns empty blocklist

<iq type='result' id='blocklist1'>
  <blocklist xmlns='http://jabber.org/protocol/blocking'/>
</iq>
    

A client SHOULD retrieve the block list after authenticating with its server and before completing any blocking or unblocking operations.

5.3 User Blocks Contact

In order for a user to block communications with a contact, 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 'http://jabber.org/protocol/blocking' namespace, where the JID to be blocked is encapsulated as the 'jid' attribute of the <item/> child element:

Example 6. Block command

<iq from='juliet@capulet.com/chamber' type='set' id='block1'>
  <block xmlns='http://jabber.org/protocol/blocking'>
    <item jid='romeo@montague.net'/>
  </block>
</iq>
    

If the server can successfully process the block command, it MUST return an IQ-result:

Example 7. Block command is successful

<iq type='result' id='block1'/>
    

The server MUST also send an IQ-set to all of the user's resources that have requested the blocklist, containing the blocked item(s):

Example 8. Block "push"

<iq to='juliet@capulet.com/chamber' type='set' id='push1'>
  <block xmlns='http://jabber.org/protocol/blocking'>
    <item jid='romeo@montague.net'/>
  </block>
</iq>

<iq to='juliet@capulet.com/balcony' type='set' id='push2'>
  <block xmlns='http://jabber.org/protocol/blocking'>
    <item jid='romeo@montague.net'/>
  </block>
</iq>
    

If the <block/> element does not contain at least one <item/> child element, the server MUST return a <bad-request/> error. The <block/> element MAY contain more than one <item/> child. Other standard XMPP stanza errors also apply; see XMPP Core [5] and Error Condition Mappings [6].

When the user blocks communications with the contact, the user's server MUST send unavailable presence information to the contact (but only if the contact is allowed to receive presence notifications from the user in accordance with the rules defined in RFC 3921).

Once the user has blocked communications with the contact, the user's server MUST NOT deliver any XML stanzas from the contact to the user. The block remains in force until the user subsequently unblocks commmunications with the contact (i.e., the duration of the block is potentially unlimited and applies across sessions).

If the contact 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:

• For message stanzas and presence stanzas (including notifications, subscriptions, and probes), the user's server MUST NOT respond and MUST NOT return an error.
• For IQ stanzas, the server MUST return an error, which SHOULD be <service-unavailable/>.

If the foregoing suggestions are followed, the user will appear offline to the contact.

If the user attempts to send an outbound stanza to the contact, the user's server MUST NOT route the stanza to the contact but instead MUST return a <not-acceptable/> error containing an application-specific error condition of <blocked/> qualified by the 'http://jabber.org/protocol/blocking#errors' namespace:

Example 9. Error: contact is blocked

<message type='error' from='romeo@montague.net' to='juliet@capulet.com'>
  <body>Can you hear me now?</body>
  <error type='cancel'>
    <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
    <blocked xmlns='http://jabber.org/protocol/blocking#errors'/>
  </error>
</message>
    

5.4 User Unblocks Contact

In order for a user to unblock communications with a contact, 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 'http://jabber.org/protocol/blocking' namespace, where the JID to be unblocked is encapsulated as the 'jid' attribute of the <item/> child element:

Example 10. Unblock contact command

<iq type='set' id='unblock1'>
  <unblock xmlns='http://jabber.org/protocol/blocking'>
    <item jid='romeo@montague.net'/>
  </unblock>
</iq>
    

If the server can successfully process the unblock command, it MUST return an IQ-result:

Example 11. Unblock contact command is successful

<iq type='result' id='unblock1'/>
    

The server MUST also send an IQ-set to all of the user's resources that have requested the blocklist, containing the unblocked item(s):

Example 12. Unblock "push"

<iq to='juliet@capulet.com/chamber' type='set' id='push3'>
  <unblock xmlns='http://jabber.org/protocol/blocking'>
    <item jid='romeo@montague.net'/>
  </unblock>
</iq>

<iq to='juliet@capulet.com/balcony' type='set' id='push4'>
  <unblock xmlns='http://jabber.org/protocol/blocking'>
    <item jid='romeo@montague.net'/>
  </unblock>
</iq>
    

When the user unblocks communications with the contact, the user's server MUST send the user's current presence information to the contact (but only if the contact is allowed to receive presence notifications from the user in accordance with the rules defined in RFC 3921).

After the user has unblocked communications with the contact, the user's server MUST deliver any subsequent XML stanzas from the contact to the user.

5.5 User Unblocks All Contacts

In order for a user to unblock communications with all contacts, 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 'http://jabber.org/protocol/blocking' namespace:

Example 13. Unblock all command

<iq type='set' id='unblock2'>
  <unblock xmlns='http://jabber.org/protocol/blocking'/>
</iq>
    

If the server can successfully process the unblock command, it MUST return an IQ-result:

Example 14. Unblock all command is successful

<iq type='result' id='unblock2'/>
    

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:

Example 15. Unblock all "push"

<iq to='juliet@capulet.com/chamber' type='set' id='push5'>
  <unblock xmlns='http://jabber.org/protocol/blocking'/>
</iq>

<iq to='juliet@capulet.com/balcony' type='set' id='push6'>
  <unblock xmlns='http://jabber.org/protocol/blocking'/>
</iq>
    

Once the user has unblocked communications with all contacts, the user's server MUST deliver any XML stanzas from those contacts to the user.

9.1 Protocol Namespaces

The XMPP Registrar [9] shall include 'http://jabber.org/protocol/blocking' and 'http://jabber.org/protocol/blocking#errors' in its registry of protocol namespaces (see <http://www.xmpp.org/registrar/namespaces.html>).

10.1 blocking

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/protocol/blocking'
    xmlns='http://jabber.org/protocol/blocking'
    elementFormDefault='qualified'>

  <xs:element name='block'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='item' minOccurs='1' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>


  <xs:element name='unblock'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='item' minOccurs='0' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>


  <xs:element name='blocklist'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='item' minOccurs='0' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='item'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='jid' type='xs:string' use='required'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>
    

10.2 blocking#errors

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/protocol/blocking#errors'
    xmlns='http://jabber.org/protocol/blocking#errors'
    elementFormDefault='qualified'>

  <xs:element name='blocked' type='empty'/>

  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>
    

1. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://www.ietf.org/rfc/rfc3921.txt>.

2. XEP-0016: Server-Based Privacy Rules <http://www.xmpp.org/extensions/xep-0016.html>.

3. RFC 2779: A Model for Presence and Instant Messaging <http://www.ietf.org/rfc/rfc2779.txt>.

4. XEP-0030: Service Discovery <http://www.xmpp.org/extensions/xep-0030.html>.

5. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://www.ietf.org/rfc/rfc3920.txt>.

6. XEP-0086: Error Condition Mappings <http://www.xmpp.org/extensions/xep-0086.html>.

7. XEP-0055: Jabber Search <http://www.xmpp.org/extensions/xep-0055.html>.

8. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

9. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the Jabber Software Foundation. For further information, see <http://www.xmpp.org/registrar/>.

Version 0.4 (2006-11-06)

Version 0.3 (2006-10-16)

Version 0.2 (2006-08-30)

Version 0.1 (2006-08-16)

Version 0.0.2 (2006-08-10)

Version 0.0.1 (2006-08-09)