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

Matthias Wimmer m at tthias.eu
Fri Dec 15 08:15:38 CST 2006


Hi Peter!

Peter Saint-Andre schrieb:
>> - 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'/>

I client which only uses blocklists will always only have the default
privacy lists active. Therefore I think it is enought to only modify
this list.
If the user creates a special privacy list for some sessions, which is
then turned active in that sessions, it should not get affected by any
setting of a client not using this privacy list.

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

Mridul just pointed out the problem of creating a new privacy list. If
such a list (which is created by the client, not the server) does not
contain all entities that have been blocked before, the block list will
get empty again.

I don't think that this is what the user will expect. IMO he will expect
additional privacy lists to also allow him to make exception from his
default privacy/blocking settings.

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

Well the question I asked is, if a JID should be returned if it has
action='deny' but only for a subset of stanza types (e.g. only for
<message/>).

> I think: not just the active privacy list, but all privacy lists.

See above. I have no strong feeling, but I'd expect that only modifying
the active list (which should be the default list) would be what a user
expects to happen.

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

Do you mean only items with action='deny' *AND* type='jid'?

I really think, that *ALL* blocking should be removed by this command,
i.e. also remove all other types of items (group, subscription and
fall-back). Else a blocklist-only client would have no change to get
privacy/blocking settings at least for his own sessions resettet to free
communication.

Think of the following list:
<item type='subscription' value='none' action='deny' order='1'/>
<item type='subscription' value='from' action='deny' order='2'/>
<item type='subscription' value='to' action='deny' order='3'/>
<item type='subscription' value='both' action='deny' order='4'/>

A blocklist-only client can only get this account working again if the
above command does delete all items with action='deny'.

... and if we delete all deny-actions, there is no need anymore for
allow-actions. So we can just remove the complete privacy list.

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

I think Privacy Lists do not require the client to request the lists
when starting a session. So when a client does not request blocklists,
we have to assume that this client users privacy lists and relies on the
fact, that they are not modified by other sessions, as long as this list
is used by the client's session.


Matthias

-- 
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-JIG mailing list