[Standards-JIG] XEP-191

Peter Saint-Andre stpeter at jabber.org
Tue Nov 7 03:40:21 UTC 2006

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



-------------- 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/20061106/eca1a916/attachment.bin>

More information about the Standards mailing list