[Standards-JIG] Problem implementing XEP-0191 / Mapping XEP-0191 on XEP-0016
mridul at sun.com
Sat Dec 16 14:44:52 UTC 2006
Please see below.
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.
>> 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 :
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
More information about the Standards