[Standards-JIG] Problem implementing XEP-0191 / Mapping XEP-0191 on XEP-0016

[Mridul]

Hi Matthias,

  Please see below.

Regards,
Mridul

Matthias Wimmer wrote:
> Mridul schrieb:
>   
>>> So I think that when Juliet retrieves the block list, she does not
>>> expect to receive the currently active privacy list (or a filtered
>>> version thereof, i.e., the set of JIDs on the currently active list that
>>> are set to action='deny'). She expects to receive the list of JIDs with
>>> which she has blocked all communications, no matter what list they are
>>> on or whether that list is active.
>>>   
>>>       
>> This would mean that block list would need to be maintained separately
>> and layered on top of the privacy lists.
>> Else, we cannot enforce this for :
>> a) any new privacy list which gets subsequently created.
>> b) attempts to modify an entry in privacy list which has been specified
>> through block list.
>>     
>
> Right.
>
>   
>> This might sound like a step backwards, but why not decouple both other
>> than from a functional point of view ?
>> That is, just decouple block lists from privacy lists and
>> use/manage/apply block list as a different layer.
>> A client which does not use block list will not
>> enable/modify/be_aware_of block list.
>> A client which does not use privacy list will not set one as active and
>> will not enable/modify/be_aware_of privacy list (wont know about default
>> list too btw).
>> This would mean that block list will need to be managed and maintained
>> seperate from privacy lists.
>>     
>
> I don't think that having two layers is a good idea. On well designed
> user interfaces, I expect users will not know if a client internally
> uses block lists or privacy lists.
>   

Good point, makes sense.

> And than it will be very confusing to a user, that doing a "unblock all"
> will only remove the blocks he set with his own client (which does block
> lists), but not the blocks he set with his other client (which does
> privacy lists).
>   

But this is kind of tricky anyway unless we split both entirely right ? 
(That is client decides to use only block list or only privacy list)
The block list client will not know anything about partial blocks/allows 
in privacy list and maintaining privacy lists consistent with block 
lists will be tricky.

> I prefere to resolve our problems by adding the following definitions to
> XEP-0016 and XEP-0191:
>
> - Define what happens, if the (active) privacy list cannot be 100%
> expressed as a blocklist. It may either be, that an error is returned in
> that case (allowing the blocklist client to reset this list by
> unblocking all) - or to return an approximation to the privacy list and
> add a marker to it, that what a server actually uses might be not
> exactly what has been returned. (Modification in XEP-0191)
>
>   

Which privacy list is to be used ? Intersection of all the lists or only 
the currently active (and so default) list ?
Peter seems to indicate the second if I am not wrong.

> - Defining an indication, that a privacy list client accepts list
> changes for active lists as well. (E.g. as a disco feature of the
> client, or an indication a client can pass with his request for the
> privacy lists to the server). This will allow blocklists to be modified
> if all sessions use block-list clients or privacy-list which support
> this feature. (Modification in XEP-0016).
>   

Yes, I had asked about this a while back too, for a slightly different 
usecase though : 
http://mail.jabber.org/pipermail/standards-jig/2006-September/012438.html
This is very useful to have even without this current set of requirements.

> - Define that blocking/unblocking commands my fail because of conflicts.
> (I.e. there are sessions neither supporting the updated version of
> privacy-lists nor the block-lists.) (Modification in XEP-0191)
>
>   

The way Peterdescribed above, if we are going to modify all lists to 
push block list change - then if a user does "unblock all" (block all) , 
wont this not mean that all lists will be emptied ? Seems to be at odds 
with how users can have separate lists for different reasons.

It would also be great to define the expected behavior if a client uses 
block lists and then tries to modify underlying privacy list (or vice 
versa) too.

Regards,
Mridul
> Matthias
>
>