[Standards-JIG] UPDATED: JEP-0191 (Simple Communications Blocking)

Mridul mridul at sun.com
Wed Nov 22 00:10:00 UTC 2006


Peter Saint-Andre wrote:
> Mridul wrote:
>
> <http://mail.jabber.org/pipermail/standards-jig/2006-November/013100.html>
>
>   
>> If blocking is supposed to be a front end to privacy list, then isn't
>> the implementation notes taking it away from this goal ?
>> Privacy lists never lead to roster changes : which is what the
>> implementation notes for 191 talking about.
>> If blocking could lead to roster change, then it is no longer a
>> frontend to privacy list.
>>     
>
> So I think we should add the 191 implementation note to 16.
>   

I would expect the reverse to happen.
There is no real need to take the user off the roster: the fact that 
userA is blocking userB need not really be communicated to userB in any 
form.
I dont think removing userB from userA's roster is required.
Simple example would be how invisibility was implemented using privacy 
list : it never resulted in user ending up with an empty roster.

You will need to maintain a block list distinct from roster anyway, so 
it might as well be better not to have any relationship between both in 
the spec.


>   
>> Also, blocking a user through privacy list always did update the
>> contact about the availablity change.
>>     
>
> Right. Is that currently different between 16 and 191?
>
>   
>> The way I was thinking of it simple terms was : blocking is to all
>> stanzas what privacy lists was to presece-out.
>> If contact gets (un)blocked through privacy list, change in status
>> would get pushed (IF he was seeing user as visible earlier : through
>> directed presence or roster/privacy list). Cant we not mirror that for
>> blocking too ?
>> If blocked -> send unavailable if contact was seeing user as
>> available, and then block.
>> If unblocked -> send available (if allowed) and then 'normal'.
>>     
>
> I think 191 already specifies that behavior, no? Consider the following
> text....
>   

Yes, you are right, I think I missed parts of this - sorry about that.

Btw, this does not talk about directed presence sent to a user.
Or is that also supposed to be handled the same way as when an 
unavailable presence is broadcasted ?

> (Section 5.3)
>
> When the user blocks communications with the contact, the user's server
> MUST send unavailable presence information to the contact (but only if
> the contact is allowed to receive presence notifications from the user
> in accordance with the rules defined in RFC 3921).
>
> (Section 5.4)
>
> When the user unblocks communications with the contact, the user's
> server MUST send the user's current presence information to the contact
> (but only if the contact is allowed to receive presence notifications
> from the user in accordance with the rules defined in RFC 3921).
>
>   
>> Just for completeness sake : there is already a difference between
>> privacy list and blocking for presence - you could send directed
>> presence even when presence-out was disabled in privacy lists : not so
>> in blocking. But this is by design for blocking.
>>     
>
> Right. It's OK for blocking to be different from privacy lists in some
> ways, because it is "simple" and doesn't provide the same level of
> flexibility (but also that reduces the complexity).
>   

Another thing that we are noticing in the new way of blocking is that it 
is applicable to the bare jid as a whole.
It would be nice if there was a concept of named blocking lists and 
different resources could define and enable the one they need.
Having a single active list per bare jid does limit the complexity (not 
sure by how much in comparison though), but it does severely limit 
usability of blocking lists in case multiple resources are logged in and 
blocking is to be enabled.

Thanks,
Mridul

> Peter
>
>   




More information about the Standards mailing list