From 2cff9f2b084cb65116df82d679bdff68ccc524a0 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Mon, 27 Nov 2006 17:59:49 +0000 Subject: [PATCH] 1.0 DRAFT git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@224 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0191.xml | 68 ++++++++++++++++++++++++++++------------------------ 1 file changed, 37 insertions(+), 31 deletions(-) diff --git a/xep-0191.xml b/xep-0191.xml index 6db30506..5da87c92 100644 --- a/xep-0191.xml +++ b/xep-0191.xml @@ -10,7 +10,7 @@ This document specifies an XMPP protocol extension for simple communications blocking. &LEGALNOTICE; 0191 - Proposed + Draft Standards Track Standards JIG @@ -22,6 +22,12 @@ None blocking &stpeter; + + 1.0 + 2006-11-21 + psa +

Per a vote of the XMPP Council, advanced status to Draft; also modified namespace to use XMPP URN.

 + 0.5 2006-11-06 @@ -77,8 +83,8 @@ -

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.

+

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 (XEP-0016). 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 is not specified herein, the relevant text in XEP-0016 shall be taken to apply.

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):

@@ -97,28 +103,28 @@ ]]> -

If the server supports the protocol defined herein, it MUST return a feature of "http://jabber.org/protocol/blocking":

+

If the server supports the protocol defined herein, it MUST return a feature of "urn:xmpp:blocking":

... - + ... ]]> -

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:

+

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:

- + ]]>

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:

- + @@ -127,16 +133,16 @@

If the user has no contacts in its blocklist, the server MUST return an IQ-result containing an empty <blocklist/> element:

- + ]]>

A client SHOULD retrieve the block list after authenticating with its server and before completing any blocking or unblocking operations.

 -

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:

+

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:

- + @@ -148,13 +154,13 @@

The server MUST also send an IQ-set to all of the user's resources that have requested the blocklist, containing the blocked item(s):

- + - + @@ -166,25 +172,25 @@
  • For presence stanzas (including notifications, subscriptions, and probes), the server MUST NOT respond and MUST NOT return an error.
  • For message stanzas, the server SHOULD return an error, which SHOULD be &unavailable;.
    • -
  • For IQ stanzas, the server MUST return an error, which SHOULD be &unavailable;.
    • +
  • 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.

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 ¬acceptable; error containing an application-specific error condition of <blocked/> qualified by the 'http://jabber.org/protocol/blocking#errors' namespace:

+

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:

Can you hear me now? - + ]]> -

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:

+

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:

- + @@ -196,13 +202,13 @@

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):

- + - + @@ -211,10 +217,10 @@

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.

 -

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:

+

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:

- + ]]>

If the server can successfully process the unblock command, it MUST return an IQ-result:

@@ -224,11 +230,11 @@

The server MUST also send an IQ-set to all of the user's resources that have requested the blocklist, containing notification of global unblocking:

- + - + ]]>

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

@@ -246,7 +252,7 @@ -

The ®ISTRAR; shall include 'http://jabber.org/protocol/blocking' and 'http://jabber.org/protocol/blocking#errors' in its registry of protocol namespaces (see &NAMESPACES;).

+

The ®ISTRAR; includes 'urn:xmpp:blocking' and 'urn:xmpp:blocking:errors' in its registry of protocol namespaces (see &NAMESPACES;).

 @@ -256,8 +262,8 @@ @@ -305,14 +311,14 @@ ]]> - + @@ -328,6 +334,6 @@ -

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

+

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