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

Peter Saint-Andre stpeter at jabber.org
Mon Dec 11 13:15:34 CST 2006


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.

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

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

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.

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.

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.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20061211/e2feea53/smime.bin


More information about the Standards-JIG mailing list