This document specifies an XMPP protocol extension for simple communications blocking.
WARNING: This Standards-Track JEP is Experimental. Publication as a Jabber Enhancement Proposal does not imply approval of this proposal by the Jabber Software Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems should not deploy implementations of this protocol until it advances to a status of Draft.
Status:
Experimental
Type:
Standards Track
Number: 0191
Version: 0.1
Last Updated: 2006-08-16
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, XMPP IM, JEP-0030
Supersedes: None
Superseded By: None
Short Name: blocking
Wiki Page: <http://wiki.jabber.org/index.php/Simple Communications Blocking (JEP-0191)>
Email:
stpeter@jabber.org
JID:
stpeter@jabber.org
This Jabber Enhancement Proposal 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.jabber.org/jsf/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/>).
The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
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 JEP 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.
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".
RFC 3921 [1] includes an XMPP protocol extension for communications blocking. Unfortunately, because that extension (privacy lists) 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 from selected users is an important feature for an instant messaging system (and is required by RFC 2779 [2]). 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.
The requirements for simple communications blocking are straightforward:
In order for a client to discover whether its server supports the protocol defined herein, it MUST send a Service Discovery [3] 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>
In order for a user to block communications from 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'/>
(Standard XMPP stanza errors apply; see XMPP Core [4] and Error Condition Mappings [5].)
Note: The <block/> element MAY contain more than one <item/> child.
Once the user has blocked communications from the contact, the user's server MUST NOT deliver any XML stanzas from the contact to the user.
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 return an error according to the following rules:
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>
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>
In order for a user to unblock communications from 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 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 command is successful
<iq type='result' id='unblock1'/>
Once the user has unblocked communications from the contact, the user's server MUST deliver any XML stanzas from the contact to the user.
If properly implemented, this protocol extension does not introduce any new security concerns above and beyond those defined in RFC 3920 and RFC 3921.
No interaction with the Internet Assigned Numbers Authority (IANA) [6] is required as a result of this JEP.
The Jabber Registrar [7] shall include 'http://jabber.org/protocol/blocking' and 'http://jabber.org/protocol/blocking#errors' in its registry of protocol namespaces (see <http://www.jabber.org/registrar/namespaces.html>).
<?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='0' 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>
<?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. RFC 2779: A Model for Presence and Instant Messaging <http://www.ietf.org/rfc/rfc2779.txt>.
3. JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>.
4. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://www.ietf.org/rfc/rfc3920.txt>.
5. JEP-0086: Error Condition Mappings <http://www.jabber.org/jeps/jep-0086.html>.
6. 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/>.
7. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.
Initial JEP version.
(psa)Added block list retrieval use case; modified block and unblock syntax to use item child element.
(psa)First draft.
(psa)END