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

Matthias Wimmer m at tthias.eu
Mon Dec 4 15:44:17 UTC 2006


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.

-- 
Matthias Wimmer      Fon +49-700 77 00 77 70
Züricher Str. 243    Fax +49-89 95 89 91 56
81476 München        http://ma.tthias.eu/



More information about the Standards mailing list