[Standards-JIG] XEP-191

Peter Saint-Andre stpeter at jabber.org
Wed Nov 15 20:48:35 UTC 2006


Peter Saint-Andre wrote:
> Peter Saint-Andre wrote:
>> Kevin Smith wrote:
>>> Peter Saint-Andre wrote:
>>>> BTW, polite blocking is what we defined in RFC 3921, so XEP-0191 as it
>>>> stands is consistent with RFC 3921 and XEP-0016. 
>>> I know, but this is the chance to change things :)
>>>
>>>> IMHO we need to think
>>>> about it a bit more before making a change. 
>>> Of course, but this is an effort to start with a proposal and a
>>> discussion :)
>>>
>>>> And really this is a social
>>>> issue (leave it up to service-level policy or individual choice) than a
>>>> technology issue per se.
>>> Well, doing polite blocking is a purely social decision. Doing bounced
>>> blocking though is a technical decision though, since it would be nice
>>> for xmpp to be a reliable protocol (i.e. without blackholes) imo. I'd
>>> just like it that, since there is a technical reason to do bounces, and
>>> a social issue which is unclear which is preferable, we could discuss
>>> any technical reasons to do polite blocking. When we start doing
>>> guaranteed delivery of whatever form, Justin's XMPP changes, or
>>> 184-Message receipts, we're looking at causing a full set of retransmits
>>> if we drop stanzas silently.
>> As we discussed in the Council meeting today [1], what if the blocking
>> user's server returns a <service-unavailable/> error to the blocked
>> contact. All that says is "sorry, no messaging delivery service is
>> available at the user's server". That may be something between "polite"
>> (black hole, no error or reporting returned) and "impolite" (e.g., an
>> error of <not-acceptable/> or somesuch).
> 
> Seeing no objections, I propose the following rules when a contact is
> blocked by a user (only the message rule is new, but I've included them
> all to provide context):
> 
> ******
> 
> 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:
> 
>     * 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 <service-unavailable/>.
> 
>     * For IQ stanzas, the server MUST return an error, which SHOULD be
> <service-unavailable/>.
> 
> ******

BTW, this is not consistent with Section 2.14 of XEP-0016, which states:

******

If a blocked entity attempts to send message or presence stanzas to the
user, the user's server SHOULD silently drop the stanza and MUST NOT
return an error to the sending entity.

If a blocked entity attempts to send an IQ stanza of type "get" or "set"
to the user, the user's server MUST return to the sending entity a
<service-unavailable/> stanza error, since this is the standard error
code sent from a client that does not understand the namespace of an IQ
get or set. IQ stanzas of other types SHOULD be silently dropped by the
server.

******

So presumably we need to make them consistent.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20061115/59e1d232/attachment.bin>


More information about the Standards mailing list