[Standards-JIG] XEP-191

Peter Saint-Andre stpeter at jabber.org
Mon Nov 6 22:54:37 UTC 2006

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


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

More information about the Standards mailing list