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


> Peter

More information about the Standards mailing list