[Standards-JIG] LAST CALL: XEP-0191 (Simple CommunicationsBlocking)

Peter Saint-Andre stpeter at jabber.org
Mon Oct 16 21:16:24 UTC 2006

Chris Mullins wrote:
> Mridul Wrote:
>> 1) If user blocks a contact , is the server expected to 
>> send an unavailable presence on behalf of the user if contact is :
>>  a) either in the roster.
>>  b) had received a directed presence earlier though not in roster.
> That's probably a good idea. Otherwise you'll go on thinking I'm online
> forever. 
> Also, when I do go offline, my server will be forbidden from sending you
> Unavailable presence, so I'll be forever "Available" to you. 
> +1


>> 2) How is server expected to respond to presence probe's in case 1 is
>> not true.
> I would think, "No Response" or <service unavailable/>. 

Point #2 of Section 5.1.3 of RFC 3921 states:

Else, if the contact is blocking presence notifications to the user's
bare JID or full JID (using either a default list or active list as
defined under Blocking Outbound Presence Notifications), the server MUST
NOT reply to the presence probe.

So here also the server MUST NOT respond to the probe.

I've clarified that in the text.

>> 3) Does blocking imply (hard) invisibility ?
> Yes, I think. And in the classic sense: I can't even send you a message
> if I'm invisible, as doing so is forbidden by my server.

Yeah, sorry.

>> 4) How are amp (and other ?) message  handling 
>> extensions to be evaluated in case contact sends 
>> user a message - as though user is offline ?
> The message is rejected by the server, not stored offline, and the
> originating user receives an error.

The server MUST NOT return an error, as described in other posts to this

>> 5) Is block list evaluation restricted to users ? Or 
>> can this include any jid (including component's) ? 
>> Full jids (with resource) or only bare jids ?
> I would like to see this include component/server JIDs ("server") and
> bare JID's ("user at server") and explicitly forbid full JIDs
> ("user at server/resource"). 
> I know Peter's take is that this should be applicable to the same JID
> scopes as privacy lists are today. 

Yes, see previous posts in this thread. We follow what's in Section 2.1
of XEP-0016.

> I would really like to see the 'no
> full jid' rule put in place though. 

I agree that's not very smart when the other entity is a user, but that
general functionality might be desirable in certain circumstances (we
can't assume that node at domain/resource is at all related to a user, it
could be some automated process, a particular user in a MUC room, etc.).


Peter Saint-Andre
Jabber Software Foundation

-------------- 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/20061016/564485d3/attachment.bin>

More information about the Standards mailing list