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

Mridul mridul at sun.com
Thu Dec 7 18:05:58 UTC 2006

Hi Matthias,

  This is similar to my observations when I was scoping this out.
We already have privacy list implementation and there does not seem to 
be an easy fit of how to map simple blocking to privacy list.
Other/similar problems we are trying to work around are :
1) How to report partial blocking thru privacy list (16 list data) as 
simple comm blocking (191 data) ? Similarly, when you remove all 
blocking through 191, how will it affect these entries in 16 privacy 
list ? What is the 'order' for an entry added through 191 ?
2) How to manage different lists being active for different resources of 
the jid (what will the block list be ? enforcing , etc) : ignore 191 in 
case non default list is active for a resource ?
3) Modifying active list while in use , if default is changed. Also, 
when default is changed by a resource - do we propagate new list as 191 
blocking list also ?

We are still going through the potential issues like you, so hopefully 
answers to these will shape our thinking better.


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

More information about the Standards mailing list