XEP-0191: Simple Communications Blocking

This document specifies an XMPP protocol extension for simple communications blocking.

NOTICE: This document is currently within Last Call or under consideration by the XMPP Council for advancement to the next stage in the JSF standards process.

XEP Information

Status: Proposed
Type: Standards Track
Number: 0191
Version: 0.3
Last Updated: 2006-10-16
Publishing Organization: Jabber Software Foundation
Approving Body: XMPP Council
Dependencies: XMPP Core, XMPP IM, XEP-0030
Supersedes: None
Superseded By: None
Short Name: blocking
Wiki Page: <http://wiki.jabber.org/index.php/Simple Communications Blocking (XEP-0191)>

Author Information

Peter Saint-Andre

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

Legal Notice

This XMPP Extension Protocol is copyright 1999 - 2006 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.xmpp.org/extensions/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).

Discussion Venue

The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Conformance Terms

The following keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Table of Contents

1. Introduction
2. Requirements
3. Relationship to Privacy Lists
4. JID Matching
5. Use Cases
5.1. User Discovers Support
5.2. User Blocks Contact
5.3. User Retrieves Block List
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

1. Introduction

RFC 3921 [1] includes an XMPP protocol extension for communications blocking, which has since been moved to Server-Based Privacy Rules [2]. 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 RFC 2779 [3]). However, the full power of privacy lists is not needed in order to block communications, so this document proposes a much simpler blocking protocol that meets the requirement specified in RFC 2779 and can be implemented much more easily in Jabber/XMPP clients and servers.

2. Requirements

The requirements for simple communications blocking are straightforward:

  1. A user must be able to block communications with a specific contact.
  2. A user should be able to determine which contacts are blocked.
  3. A user should be able to unblock communications with a specific contact.

3. Relationship to Privacy Lists

The simple communications blocking protocol specified herein is intended to be a user-friendly "front end" to a subset of the functionality defined by the privacy lists protocol. If a service deploys both privacy lists and simple communications blocking, both protocols MUST use the same back-end data store.

Wherever possible, this document attempts to define a protocol that is fully consistent with XEP-0016. If a particular aspect of functionality (e.g., stanza processing or JID matching rules) is not specified herein, the relevant text in XEP-0016 shall be taken to apply.

4. JID Matching

Matching of JIDs as specified in the 'jid' attribute of the <item/> element SHOULD proceed in the following order (this is consistent with XEP-0016):

  1. <user@domain/resource> (only that resource matches)
  2. <user@domain> (any resource matches)
  3. <domain/resource> (only that resource matches)
  4. <domain> (the domain itself matches, as does any user@domain, domain/resource, or address containing a subdomain)

5. Use Cases

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='bilbo@tolkien.lit/shire' to='tolkien.lit' 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='bilbo@tolkien.lit/shire' to='tolkien.lit' type='result' id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='http://jabber.org/protocol/blocking'/>
    ...
  </query>
</iq>

5.2 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 3. Block command

<iq 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 4. Block command is successful

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

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

Note: The <block/> element MAY contain more than one <item/> child.

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:

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 5. 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.3 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 6. 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 7. 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 8. 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.

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 9. 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 10. Unblock contact command is successful

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

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 11. 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 12. Unblock all command is successful

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

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

6. Implementation Notes

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.

A service MAY also filter blocking users out of searches performed on user directories (see, for example, Jabber Search [7]); however, that functionality is out of scope for this specification.

7. Security Considerations

If properly implemented, this protocol extension does not introduce any new security concerns above and beyond those defined in RFC 3920 and RFC 3921.

8. IANA Considerations

No interaction with the Internet Assigned Numbers Authority (IANA) [8] is required as a result of this specification.

9. XMPP Registrar Considerations

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. XML Schema

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>

11. Acknowledgements

Thanks to Valerie Mercier, Maciek Niedzielski, and Remko Tronçon for their feedback.

Notes

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/>.

Revision History

Version 0.3 (2006-10-16)

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.

(psa)

Version 0.2 (2006-08-30)

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.

(psa)

Version 0.1 (2006-08-16)

Initial version.

(psa)

Version 0.0.2 (2006-08-10)

Added block list retrieval use case; modified block and unblock syntax to use item child element.

(psa)

Version 0.0.1 (2006-08-09)

First draft.

(psa)

END