mirror of https://github.com/moparisthebest/xeps
263 lines
13 KiB
XML
263 lines
13 KiB
XML
<?xml version='1.0' encoding='UTF-8'?>
|
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
|
%ents;
|
|
]>
|
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
|
<xep>
|
|
<header>
|
|
<title>Simple Communications Blocking</title>
|
|
<abstract>This document specifies an XMPP protocol extension for simple communications blocking.</abstract>
|
|
&LEGALNOTICE;
|
|
<number>0191</number>
|
|
<status>Experimental</status>
|
|
<type>Standards Track</type>
|
|
<jig>Standards JIG</jig>
|
|
<dependencies>
|
|
<spec>XMPP Core</spec>
|
|
<spec>XMPP IM</spec>
|
|
<spec>XEP-0030</spec>
|
|
</dependencies>
|
|
<supersedes>None</supersedes>
|
|
<supersededby>None</supersededby>
|
|
<shortname>blocking</shortname>
|
|
&stpeter;
|
|
<revision>
|
|
<version>0.2</version>
|
|
<date>2006-08-30</date>
|
|
<initials>psa</initials>
|
|
<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>
|
|
</revision>
|
|
<revision>
|
|
<version>0.1</version>
|
|
<date>2006-08-16</date>
|
|
<initials>psa</initials>
|
|
<remark><p>Initial version.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.0.2</version>
|
|
<date>2006-08-10</date>
|
|
<initials>psa</initials>
|
|
<remark><p>Added block list retrieval use case; modified block and unblock syntax to use item child element.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.0.1</version>
|
|
<date>2006-08-09</date>
|
|
<initials>psa</initials>
|
|
<remark><p>First draft.</p></remark>
|
|
</revision>
|
|
</header>
|
|
<section1 topic='Introduction' anchor='proto'>
|
|
<p>&rfc3921; 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 &rfc2779;). 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 <cite>RFC 2779</cite> and can be implemented much more easily in Jabber/XMPP clients and servers.</p>
|
|
</section1>
|
|
<section1 topic='Requirements' anchor='proto'>
|
|
<p>The requirements for simple communications blocking are straightforward:</p>
|
|
<ol start='1'>
|
|
<li>A user must be able to block communications from a specific contact.</li>
|
|
<li>A user should be able to determine which contacts are blocked.</li>
|
|
<li>A user should be able to unblock communications from a specific contact.</li>
|
|
</ol>
|
|
</section1>
|
|
<section1 topic='Use Cases' anchor='usecases'>
|
|
<section2 topic='User Discovers Support' anchor='disco'>
|
|
<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>
|
|
<example caption='Service discovery request'><![CDATA[
|
|
<iq from='bilbo@tolkien.lit/shire' to='tolkien.lit' type='get' id='disco1'>
|
|
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
|
</iq>
|
|
]]></example>
|
|
<p>If the server supports the protocol defined herein, it MUST return a feature of "http://jabber.org/protocol/blocking":</p>
|
|
<example caption='Service discovery response'><![CDATA[
|
|
<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>
|
|
]]></example>
|
|
</section2>
|
|
<section2 topic='User Blocks Contact' anchor='block'>
|
|
<p>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:</p>
|
|
<example caption='Block command'><![CDATA[
|
|
<iq type='set' id='block1'>
|
|
<block xmlns='http://jabber.org/protocol/blocking'>
|
|
<item jid='romeo@montague.net'/>
|
|
</block>
|
|
</iq>
|
|
]]></example>
|
|
<p>If the server can successfully process the block command, it MUST return an IQ-result:</p>
|
|
<example caption='Block command is successful'><![CDATA[
|
|
<iq type='result' id='block1'/>
|
|
]]></example>
|
|
<p>(Standard XMPP stanza errors apply; see &xmppcore; and &xep0086;.)</p>
|
|
<p>Note: The <block/> element MAY contain more than one <item/> child.</p>
|
|
<p>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.</p>
|
|
<p>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:</p>
|
|
<ul>
|
|
<li>For presence stanzas, it is NOT RECOMMENDED to return an error.</li>
|
|
<li>For message stanzas, the server MAY return an error, which SHOULD be &unavailable;.</li>
|
|
<li>For IQ stanzas, the server MUST return an error, which SHOULD be &unavailable;.</li>
|
|
</ul>
|
|
<p>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 ¬acceptable; error containing an application-specific error condition of <blocked/> qualified by the 'http://jabber.org/protocol/blocking#errors' namespace:</p>
|
|
<example caption='Error: contact is blocked'><![CDATA[
|
|
<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>
|
|
]]></example>
|
|
</section2>
|
|
<section2 topic='User Retrieves Block List' anchor='blocklist'>
|
|
<p>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:</p>
|
|
<example caption='Client requests blocklist'><![CDATA[
|
|
<iq type='get' id='blocklist1'>
|
|
<blocklist xmlns='http://jabber.org/protocol/blocking'/>
|
|
</iq>
|
|
]]></example>
|
|
<p>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:</p>
|
|
<example caption='Server returns blocklist with items'><![CDATA[
|
|
<iq type='result' id='blocklist1'>
|
|
<blocklist xmlns='http://jabber.org/protocol/blocking'>
|
|
<item jid='romeo@montague.net'/>
|
|
<item jid='iago@shakespeare.lit'/>
|
|
</blocklist>
|
|
</iq>
|
|
]]></example>
|
|
<p>If the user has no contacts in its blocklist, the server MUST return an IQ-result containing an empty <blocklist/> element:</p>
|
|
<example caption='Server returns empty blocklist'><![CDATA[
|
|
<iq type='result' id='blocklist1'>
|
|
<blocklist xmlns='http://jabber.org/protocol/blocking'/>
|
|
</iq>
|
|
]]></example>
|
|
<p>A client SHOULD retrieve the block list after authenticating with its server.</p>
|
|
</section2>
|
|
<section2 topic='User Unblocks Contact' anchor='unblock'>
|
|
<p>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:</p>
|
|
<example caption='Unblock contact command'><![CDATA[
|
|
<iq type='set' id='unblock1'>
|
|
<unblock xmlns='http://jabber.org/protocol/blocking'>
|
|
<item jid='romeo@montague.net'/>
|
|
</unblock>
|
|
</iq>
|
|
]]></example>
|
|
<p>If the server can successfully process the unblock command, it MUST return an IQ-result:</p>
|
|
<example caption='Unblock contact command is successful'><![CDATA[
|
|
<iq type='result' id='unblock1'/>
|
|
]]></example>
|
|
<p>Once the user has unblocked communications from the contact, the user's server MUST deliver any XML stanzas from the contact to the user.</p>
|
|
</section2>
|
|
<section2 topic='User Unblocks All Contacts' anchor='unblockall'>
|
|
<p>In order for a user to unblock communications from 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:</p>
|
|
<example caption='Unblock all command'><![CDATA[
|
|
<iq type='set' id='unblock2'>
|
|
<unblock xmlns='http://jabber.org/protocol/blocking'/>
|
|
</iq>
|
|
]]></example>
|
|
<p>If the server can successfully process the unblock command, it MUST return an IQ-result:</p>
|
|
<example caption='Unblock all command is successful'><![CDATA[
|
|
<iq type='result' id='unblock2'/>
|
|
]]></example>
|
|
<p>Once the user has unblocked communications from all contacts, the user's server MUST deliver any XML stanzas from those contacts to the user.</p>
|
|
</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 ®ISTRAR; shall include 'http://jabber.org/protocol/blocking' and 'http://jabber.org/protocol/blocking#errors' in its registry of protocol namespaces (see &NAMESPACES;).</p>
|
|
</section2>
|
|
</section1>
|
|
<section1 topic='XML Schema' anchor='schema'>
|
|
<section2 topic='blocking' anchor='schema-blocking'>
|
|
<code><![CDATA[
|
|
<?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>
|
|
]]></code>
|
|
</section2>
|
|
<section2 topic='blocking#errors' anchor='schema-blocking-errors'>
|
|
<code><![CDATA[
|
|
<?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>
|
|
]]></code>
|
|
</section2>
|
|
</section1>
|
|
<section1 topic='Acknowledgements' anchor='ack'>
|
|
<p>Thanks to Valerie Mercier, Maciek Niedzielski, and Remko Tronçon for their feedback.</p>
|
|
</section1>
|
|
</xep>
|