From d7d047e293b7fb4589ab21bc247915e5a10e3046 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Mon, 27 Nov 2006 18:00:02 +0000 Subject: [PATCH] 1.5 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@225 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0016.xml | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-) diff --git a/xep-0016.xml b/xep-0016.xml index d16aff05..094ede63 100644 --- a/xep-0016.xml +++ b/xep-0016.xml @@ -23,9 +23,9 @@ &stpeter; 1.5 - 2006-11-21 + 2006-11-27 psa -

In order to track XEP-0191, specified that server should not ignore messages from blocked entities but instead should return a <service-unavailable/> error.

 +

Modified message stanza handling (server should return <service-unavailable/> error) and added implementation note to maintain consistency with XEP-0191. error.

 1.4 @@ -85,10 +85,10 @@

Almost all types of Instant Messaging (IM) applications have found it necessary to develop some method for a user to block the receipt of messages and packets from other users (the rationale for such blockage depends on the needs of the individual user). This document defines a flexible method for communications blocking.

Note: The protocol specified herein MAY be used in conjunction with &xep0191;; see XEP-0191 for details.

-

The remainder of this document has been copied without modification from Section 10 of &rfc3921;.

 +

This section has been copied without modification from Section 10 of &rfc3921;, with the exception of the message stanza handling rule in the Blocked Entity Attempts to Communicate with User subsection.

Most instant messaging systems have found it necessary to implement some method for users to block communications from particular other users (this is also required by sections 5.1.5, 5.1.15, 5.3.2, and 5.4.10 of &rfc2779;. In XMPP this is done by managing one's privacy lists using the 'jabber:iq:privacy' namespace.

Server-side privacy lists enable successful completion of the following use cases:

    @@ -735,7 +735,7 @@

    If a blocked entity 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:

    • 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 message stanzas, the server SHOULD return an error, which SHOULD be &unavailable;. Until version 1.5 of this document (therefore also in RFC 3921), it was recommended to silently ignore message stanzas, which unfortunately resulted in a delivery "black hole" regarding message stanzas.
    • 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.

    @@ -785,6 +785,22 @@ + +

    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.

    +

    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.

    +     + +

    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 &IANA; is required as a result of this specification.

    +     + + +

    The ®ISTRAR; already includes 'jabber:iq:privacy' in its registry of protocol namespaces (see &NAMESPACES;).

    +     +     +