mirror of https://github.com/moparisthebest/xeps
XEP-0191: Allow blocking arbitrary JIDs
This commit is contained in:
Sam Whited
parent
ea22a77bc6
commit
c04c08d6ac
56
xep-0191.xml
56
xep-0191.xml
|
|
@ -7,7 +7,7 @@
|
|||
<xep>
|
||||
<header>
|
||||
<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>
|
||||
<abstract>This document specifies an XMPP protocol extension for communications blocking.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0191</number>
|
||||
<status>Draft</status>
|
||||
|
|
@ -22,6 +22,12 @@
|
|||
<supersededby>None</supersededby>
|
||||
<shortname>blocking</shortname>
|
||||
&stpeter;
|
||||
<revision>
|
||||
<version>1.3</version>
|
||||
<date>2015-03-12</date>
|
||||
<initials>ssw</initials>
|
||||
<remark><p>Clarify that arbitrary JIDs may be blocked to match current usage of this spec in the wild.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>1.2</version>
|
||||
<date>2012-07-18</date>
|
||||
|
|
@ -91,9 +97,9 @@
|
|||
<section1 topic='Requirements' anchor='reqs'>
|
||||
<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>
|
||||
<li>A user must be able to block communications with a specific JID.</li>
|
||||
<li>A user should be able to determine which JIDs are blocked.</li>
|
||||
<li>A user should be able to unblock communications with a specific JID.</li>
|
||||
</ol>
|
||||
</section1>
|
||||
|
||||
|
|
@ -119,13 +125,13 @@
|
|||
</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>
|
||||
<p>In order for a client to request a user's list of blocked JIDs (e.g., in order to determine whether to unblock a JID), 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[
|
||||
<iq type='get' id='blocklist1'>
|
||||
<blocklist xmlns='urn:xmpp: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>
|
||||
<p>If the user has any JIDs 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 JID:</p>
|
||||
<example caption='Server returns blocklist with items'><![CDATA[
|
||||
<iq type='result' id='blocklist1'>
|
||||
<blocklist xmlns='urn:xmpp:blocking'>
|
||||
|
|
@ -134,7 +140,7 @@
|
|||
</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>
|
||||
<p>If the user has no JIDs 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='urn:xmpp:blocking'/>
|
||||
|
|
@ -143,8 +149,8 @@
|
|||
<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>
|
||||
<section2 topic='User Blocks JID' anchor='block'>
|
||||
<p>In order for a user to block communications with a JID, 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[
|
||||
<iq from='juliet@capulet.com/chamber' type='set' id='block1'>
|
||||
<block xmlns='urn:xmpp:blocking'>
|
||||
|
|
@ -171,17 +177,17 @@
|
|||
</iq>
|
||||
]]></example>
|
||||
<p>If the <block/> element does not contain at least one <item/> child element, the server MUST return a &badrequest; error. The <block/> element MAY contain more than one <item/> child. Other standard XMPP stanza errors also apply; see &xmppcore; and &xep0086;.</p>
|
||||
<p>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 <cite>RFC 3921</cite>).</p>
|
||||
<p>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).</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 handle the stanza according to the following rules:</p>
|
||||
<p>When the user blocks communications with a JID, the user's server MUST send unavailable presence information to the JID (but only if the JID is allowed to receive presence notifications from the user in accordance with the rules defined in <cite>RFC 3921</cite>).</p>
|
||||
<p>Once the user has blocked communications with a JID, the user's server MUST NOT deliver any XML stanzas from the JID to the user. The block remains in force until the user subsequently unblocks commmunications with the JID (i.e., the duration of the block is potentially unlimited and applies across sessions).</p>
|
||||
<p>If a blocked JID 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:</p>
|
||||
<ul>
|
||||
<li>For presence stanzas (including notifications, subscriptions, and probes), the server MUST NOT respond and MUST NOT return an error.</li>
|
||||
<li>For message stanzas, the server SHOULD return an error, which SHOULD be &unavailable;.</li>
|
||||
<li>For IQ stanzas of type "get" or "set", the server MUST return an error, which SHOULD be &unavailable;. IQ stanzas of other types MUST be silently dropped by the server.</li>
|
||||
</ul>
|
||||
<p>If the foregoing suggestions are followed, the user will appear offline to the contact.</p>
|
||||
<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 'urn:xmpp:blocking:errors' namespace:</p>
|
||||
<example caption='Error: contact is blocked'><![CDATA[
|
||||
<p>If the foregoing suggestions are followed, the user will appear offline to the blocked JID.</p>
|
||||
<p>If the user attempts to send an outbound stanza to the JID, the user's server MUST NOT route the stanza to the JID but instead MUST return a ¬acceptable; error containing an application-specific error condition of <blocked/> qualified by the 'urn:xmpp:blocking:errors' namespace:</p>
|
||||
<example caption='Error: JID is blocked'><![CDATA[
|
||||
<message type='error' from='romeo@montague.net' to='juliet@capulet.com'>
|
||||
<body>Can you hear me now?</body>
|
||||
<error type='cancel'>
|
||||
|
|
@ -192,9 +198,9 @@
|
|||
]]></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[
|
||||
<section2 topic='User Unblocks JID' anchor='unblock'>
|
||||
<p>In order for a user to unblock communications with a JID, 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 JID command'><![CDATA[
|
||||
<iq type='set' id='unblock1'>
|
||||
<unblock xmlns='urn:xmpp:blocking'>
|
||||
<item jid='romeo@montague.net'/>
|
||||
|
|
@ -202,7 +208,7 @@
|
|||
</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[
|
||||
<example caption='Unblock JID command is successful'><![CDATA[
|
||||
<iq type='result' id='unblock1'/>
|
||||
]]></example>
|
||||
<p>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):</p>
|
||||
|
|
@ -219,12 +225,12 @@
|
|||
</unblock>
|
||||
</iq>
|
||||
]]></example>
|
||||
<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>
|
||||
<p>When the user unblocks communications with a JID, the user's server MUST send the user's current presence information to the JID (but only if the JID 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 a JID, the user's server MUST deliver any subsequent XML stanzas from the JID 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>
|
||||
<section2 topic='User Unblocks All blocked JIDs' anchor='unblockall'>
|
||||
<p>In order for a user to unblock communications with all JIDs, 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[
|
||||
<iq type='set' id='unblock2'>
|
||||
<unblock xmlns='urn:xmpp:blocking'/>
|
||||
|
|
@ -244,7 +250,7 @@
|
|||
<unblock xmlns='urn:xmpp:blocking'/>
|
||||
</iq>
|
||||
]]></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>
|
||||
<p>Once the user has unblocked communications with all JIDs, the user's server MUST deliver any XML stanzas from those JIDs to the user.</p>
|
||||
</section2>
|
||||
|
||||
</section1>
|
||||
|
|
@ -262,7 +268,7 @@
|
|||
<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>
|
||||
<li><p>If one of a user's clients makes active something other than the default privacy list, the user may receive communications from JIDs that 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>
|
||||
|
|
|
|||
Loading…
Reference in New Issue