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

Mridul mridul at sun.com
Mon Oct 16 22:21:15 UTC 2006


Hi Peter,

  Thanks for the clarifications - just so that I understand this 
correctly : please see inline.

Thanks,
Mridul

Peter Saint-Andre wrote:
> 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
>>     
>
> Added.
>
>   
>>> 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
> thread.
>   

In this usecase , how is the server supposed to handle the message ? As 
though user is unavailable ?

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

The more I think about it , it might make sense to just allow block list 
to specify bare jid's.
That way , evaluating a block for any resource will result in the same 
answer.

I was actually thinking of this to block messages from subset of 
participants in a muc , some bots , etc .. but now I am not very sure , 
there can be alternate ways of achieving those.

Regards,
Mridul

> Peter
>
>   




More information about the Standards mailing list