mirror of https://github.com/moparisthebest/xeps
1.2rc2
This commit is contained in:
Peter Saint-Andre
parent
0e0ef91a65
commit
e6c989ec64
79
xep-0191.xml
79
xep-0191.xml
|
|
@ -6,11 +6,12 @@
|
|||
<?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>
|
||||
<title>Blocking Command</title>
|
||||
<abstract>This document specifies an XMPP protocol extension for communications blocking that is intended to be simpler than privacy lists (XEP-0016).</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0191</number>
|
||||
<status>Draft</status>
|
||||
<interim/>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
<dependencies>
|
||||
|
|
@ -22,6 +23,12 @@
|
|||
<supersededby>None</supersededby>
|
||||
<shortname>blocking</shortname>
|
||||
&stpeter;
|
||||
<revision>
|
||||
<version>1.2rc1</version>
|
||||
<date>in progress, last updated 2012-06-06</date>
|
||||
<initials>psa</initials>
|
||||
<remark><p>Changed the title and rearranged several sections.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>1.1</version>
|
||||
<date>2007-02-15</date>
|
||||
|
|
@ -77,40 +84,22 @@
|
|||
<remark><p>First draft.</p></remark>
|
||||
</revision>
|
||||
</header>
|
||||
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<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 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>
|
||||
<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>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Requirements' anchor='reqs'>
|
||||
<p>The requirements for simple communications blocking are straightforward:</p>
|
||||
<p>The requirements for communications blocking are straightforward:</p>
|
||||
<ol start='1'>
|
||||
<li>A user must be able to block communications with 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 with a specific contact.</li>
|
||||
</ol>
|
||||
</section1>
|
||||
<section1 topic='Relationship to Privacy Lists' anchor='privacy'>
|
||||
<p>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 (<cite>XEP-0016</cite>). If a service deploys both privacy lists and simple communications blocking, the service MUST use the same back-end data store for both protocols. (Note: Wherever possible, this document attempts to define a protocol that is fully consistent with <cite>XEP-0016</cite>; if a particular aspect of functionality is not specified herein, the relevant text in <cite>XEP-0016</cite> shall be taken to apply.)</p>
|
||||
<p>A service SHOULD map the blocklist to the default privacy list, where each blocked JID is represented as a privacy list item of type "jid" and action "deny". <note>An implementation MUST NOT block communications from one of a user's resources to another, even if the user happens to define a rule that would otherwise result in that behavior.</note> If this is done and none of the user's clients ever use the privacy lists protocol, then the blocklist will always apply. This mapping has the following implications:</p>
|
||||
<ol start='1'>
|
||||
<li><p>If all of a user's clients always use simple communications blocking, then the default privacy list will be equivalent to the blocklist and the default privacy list will be a kind of "virtual list" (in the sense that it is never modified directly by any of the clients).</p></li>
|
||||
<li><p>If one of a user's clients uses privacy lists instead of blocklists and modifies the default privacy list by removing a blocked JID or blocking a new JID, then that change will be reflected in the blocklist.</p></li>
|
||||
<li><p>If one of a user's clients uses privacy lists and does anything but block or unblock a JID, then that change will not be reflected in the blocklist (since blocklists cannot represent anything except blocked JIDs).</p></li>
|
||||
<li><p>If one of a user's clients removes the default privacy list and substitutes a new list for the old list, the blocked JIDs in the new default privacy list (if any) will become the new blocklist.</p></li>
|
||||
<li><p>If one of a user's clients makes active something other than the default privacy list, the user may receive communications from contacts who are blocked in the default list.</p></li>
|
||||
</ol>
|
||||
<p>Because of the potential for confusion between block lists and privacy lists, it is NOT RECOMMENDED for a client to request both the block list and privacy lists in the same session.</p>
|
||||
<p>The priority of blocked (jid+deny) items in the privacy list SHOULD be such that they come first in the privacy list.</p>
|
||||
</section1>
|
||||
<section1 topic='JID Matching' anchor='matching'>
|
||||
<p>Matching of JIDs as specified in the 'jid' attribute of the <item/> element SHOULD proceed in the following order (this is consistent with <cite>XEP-0016</cite>):</p>
|
||||
<ol>
|
||||
<li><user@domain/resource> (only that resource matches)</li>
|
||||
<li><user@domain> (any resource matches)</li>
|
||||
<li><domain/resource> (only that resource matches)</li>
|
||||
<li><domain> (the domain itself matches, as does any user@domain or domain/resource)</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[
|
||||
|
|
@ -129,6 +118,7 @@
|
|||
</iq>
|
||||
]]></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 'urn:xmpp:blocking' namespace:</p>
|
||||
<example caption='Client requests blocklist'><![CDATA[
|
||||
|
|
@ -153,6 +143,7 @@
|
|||
]]></example>
|
||||
<p>A client SHOULD retrieve the block list after authenticating with its server and before completing any blocking or unblocking operations.</p>
|
||||
</section2>
|
||||
|
||||
<section2 topic='User Blocks Contact' anchor='block'>
|
||||
<p>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 'urn:xmpp: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[
|
||||
|
|
@ -201,6 +192,7 @@
|
|||
</message>
|
||||
]]></example>
|
||||
</section2>
|
||||
|
||||
<section2 topic='User Unblocks Contact' anchor='unblock'>
|
||||
<p>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 'urn:xmpp: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[
|
||||
|
|
@ -231,6 +223,7 @@
|
|||
<p>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 <cite>RFC 3921</cite>).</p>
|
||||
<p>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.</p>
|
||||
</section2>
|
||||
|
||||
<section2 topic='User Unblocks All Contacts' anchor='unblockall'>
|
||||
<p>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 'urn:xmpp:blocking' namespace:</p>
|
||||
<example caption='Unblock all command'><![CDATA[
|
||||
|
|
@ -254,22 +247,52 @@
|
|||
]]></example>
|
||||
<p>Once the user has unblocked communications with 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='Relationship to Privacy Lists' anchor='privacy'>
|
||||
<p>The 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 (<cite>XEP-0016</cite>). If a service deploys both privacy lists and the blocking command, the service MUST use the same back-end data store for both protocols. (Note: Wherever possible, this document attempts to define a protocol that is fully consistent with <cite>XEP-0016</cite>; if a particular aspect of functionality is not specified herein, the relevant text in <cite>XEP-0016</cite> shall be taken to apply.)</p>
|
||||
<p>A service SHOULD map the blocklist to the default privacy list, where each blocked JID is represented as a privacy list item of type "jid" and action "deny". <note>An implementation MUST NOT block communications from one of a user's resources to another, even if the user happens to define a rule that would otherwise result in that behavior.</note> If this is done and none of the user's clients ever use the privacy lists protocol, then the blocklist will always apply. This mapping has the following implications:</p>
|
||||
<ol start='1'>
|
||||
<li><p>If all of a user's clients always use the blocking command, then the default privacy list will be equivalent to the blocklist and the default privacy list will be a kind of "virtual list" (in the sense that it is never modified directly by any of the clients).</p></li>
|
||||
<li><p>If one of a user's clients uses privacy lists instead of blocklists and modifies the default privacy list by removing a blocked JID or blocking a new JID, then that change will be reflected in the blocklist.</p></li>
|
||||
<li><p>If one of a user's clients uses privacy lists and does anything but block or unblock a JID, then that change will not be reflected in the blocklist (since blocklists cannot represent anything except blocked JIDs).</p></li>
|
||||
<li><p>If one of a user's clients removes the default privacy list and substitutes a new list for the old list, the blocked JIDs in the new default privacy list (if any) will become the new blocklist.</p></li>
|
||||
<li><p>If one of a user's clients makes active something other than the default privacy list, the user may receive communications from contacts who are blocked in the default list.</p></li>
|
||||
</ol>
|
||||
<p>Because of the potential for confusion between block lists and privacy lists, it is NOT RECOMMENDED for a client to request both the block list and privacy lists in the same session.</p>
|
||||
<p>The priority of blocked (jid+deny) items in the privacy list SHOULD be such that they come first in the privacy list.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='JID Matching' anchor='matching'>
|
||||
<p>Matching of JIDs as specified in the 'jid' attribute of the <item/> element SHOULD proceed in the following order (this is consistent with <cite>XEP-0016</cite>):</p>
|
||||
<ol>
|
||||
<li><user@domain/resource> (only that resource matches)</li>
|
||||
<li><user@domain> (any resource matches)</li>
|
||||
<li><domain/resource> (only that resource matches)</li>
|
||||
<li><domain> (the domain itself matches, as does any user@domain or domain/resource)</li>
|
||||
</ol>
|
||||
</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; includes 'urn:xmpp:blocking' and 'urn:xmpp: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[
|
||||
|
|
@ -333,6 +356,7 @@
|
|||
</xs:schema>
|
||||
]]></code>
|
||||
</section2>
|
||||
|
||||
<section2 topic='blocking:errors' anchor='schema-blocking-errors'>
|
||||
<code><![CDATA[
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
|
|
@ -361,8 +385,11 @@
|
|||
</xs:schema>
|
||||
]]></code>
|
||||
</section2>
|
||||
|
||||
</section1>
|
||||
|
||||
<section1 topic='Acknowledgements' anchor='ack'>
|
||||
<p>Thanks to Valerie Mercier, Maciek Niedzielski, Kevin Smith, and Remko Tronçon for their feedback.</p>
|
||||
</section1>
|
||||
|
||||
</xep>
|
||||
|
|
|
|||
Loading…
Reference in New Issue