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

Mridul mridul at sun.com
Fri Dec 15 13:57:40 UTC 2006


Peter Saint-Andre wrote:
> Hi Matthias!
>
> These are good questions. Some tentative thoughts below.
>
> Matthias Wimmer wrote:
>   
>> Hi!
>>
>> XEP-0191 requires a server implementing both XEP-0016 and XEP-0191 to
>> use the same back-end data store for both protocols. Therefore I am
>> currently trying to find a mapping of Block-lists to privacy lists.
>>     
>
> That is possible. Mapping in the other direction is not possible, since
> block lists are "simplified" (equivalent to the "block all comms" option
> in privacy lists).
>
>   
>> The following mappings I'd like to discuss here. Please comment, if you
>> consider them to be okay, or if you have suggestions on how to do it
>> better. Especially note my last clause with a problem I have not found a
>> solution for yet.
>>
>> - XEP-0191 Usecase 5.2: User Retrieves Block List
>>
>> Blocklists do not know about multiple lists, therefore retrieving a
>> user's block list would return the currently active privacy list (which
>> is as long as a client does not mix XEP-0016 and XEP-0191 in one session
>> the same as the default privacy list).
>>     
>
> I'm not sure exactly how to think about what the block list means in
> terms of privacy lists. Let's say Juliet adds Romeo to her block list.
> >From her perspective, that means she will block all comms with Romeo for
> all time (until and unless she unblocks). I think that is equivalent to
> adding the following item to *all* of her privacy lists:
>
>    <item type='jid'
>          value='romeo at montague.lit'
>          action='deny'/>
>
> 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.


>   
>> Not all privacy lists can be expressed as a block list. E.g. the
>> following rules can be defined using privacy lists, but not expressed as
>> a blocklist (just examples, there exist more such cases):
>> - Accept stanzas from julia at capulet.example.com, but block stanzas from
>> all other users of capulet.example.com.
>> - Block only presences from a user, but accept messages.
>>
>> What should be returned by the server if a user is requesting the
>> blocklist in these cases? Possible results:
>> - Send back a stanza error telling that the current privacy list cannot
>> be expressed as a blocklist. A client can then "reset" the privacy list
>> be doing a "unblock all".
>> - Send back a blocklist that matches the privacy lists as closed as
>> possible. But in that case a user might not understand why some stanzas
>> are passing, that seem to be blocked, or why some stanzas are blocked,
>> that seem to be allowed.
>>     
>
> I think: return the list of JIDs for which the user has defined
> action='deny'. Anything else is guesswork.
>
> This means that block lists trump privacy lists in a way, I guess.
>
>   

Of the two options that Matthias mentions above, what happens if user 
tries first ? (unblock all)
Will that be applicable to only entries which have action='deny' ? or to 
all entries in privacy list ?

>> - XEP-0191 Usecase 5.3: User Blocks Contact
>>
>> The server will modify the active privacy list by inserting a new item:
>> <item action='deny' order='0' value='$blockedjid' type='jid'/> and
>> incrementing the order attributes' values for all existing items.
>> (Probably followed by a compacting of the privacy list, that removes all
>> insignificant items on the list.)
>>     
>
> I think: not just the active privacy list, but all privacy lists.
>
>   
>> - XEP-0191 Usecase 5.4: User Unblocks Contact
>>
>> The server will modify the active privacy list by inserting a new item:
>> <item action='allow' order='0' value='$unblockedjid' type='jid'/> and
>> incrementing the order attributes' values for all existing items.
>> (Probably followed by the same compacting as above.)
>>     
>
> Again, I think: all privacy lists.
>
>   
>> - XEP-0191 Usecase 5.5: User Unblocks All Contacts
>>
>> The server will:
>> 1. Decline the active list
>> 2. If the default list has been the same as the active list, it will
>> decline the default list
>> 3. Remove the list, that has been active.
>>     
>
> I think the server should modify all privacy lists to remove
> action='deny' JIDs.
>
>   
>> - Remaining problem
>>
>> All concurrent sessions of a user that use (only) blocklists will
>> operate on the same privacy list (the default privacy list). Privacy
>> lists are not allowed to be changed, if they are used by another
>> session. Therefore if we map blocklists to privacy lists, it seems, that
>> a client is not able to block/unblock anything if a second session of
>> the same user exists at the same time.
>>     
>
> Hmm.
>
> Well, a few thoughts:
>
> 1. Don't use privacy lists on the client side unless you really need
> that complexity -- use the block list instead.
>   

We have the case of different clients supporting : a) only privacy list 
, b) only block lists, c) both.
A single user might use two clients at different times (home/office) 
which fall into different categories above.
Or different resources might be connected at same time, which can also 
fall into different categories above.


> 2. Clients must not request and modify both privacy lists and the block
> list in the same session -- do one or the other, but not both.
>   

 From above : If two resources for a user are logged in, one supporting 
(a) and another supporting (b) and client (b) modifies block list - 
there is need to propagate this to (a) in some way : vice versa too btw.

> 3. If only the block list has been requested by each session, then the
> block list can be modified and that change will be pushed out to all
> sessions.
>   

You are right about this - similar to clients using only privacy lists. 
Mix of both is where we start seeing problems.

> 4. If one session has requested privacy lists and has activated one of
> the lists, then we have a problem. I'm not sure how to handle that yet,
> since if my reasoning is correct above then a change to the block list
> will modify all the privacy lists and one of those may be active. Hrm.
>   

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.

Regards,
Mridul

> Peter
>
>   




More information about the Standards mailing list