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

Matthias Wimmer m at tthias.eu
Fri Dec 15 14:32:51 UTC 2006

Mridul schrieb:
>> 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.


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

I don't think that having two layers is a good idea. On well designed
user interfaces, I expect users will not know if a client internally
uses block lists or privacy lists.
And than it will be very confusing to a user, that doing a "unblock all"
will only remove the blocks he set with his own client (which does block
lists), but not the blocks he set with his other client (which does
privacy lists).

I prefere to resolve our problems by adding the following definitions to
XEP-0016 and XEP-0191:

- Define what happens, if the (active) privacy list cannot be 100%
expressed as a blocklist. It may either be, that an error is returned in
that case (allowing the blocklist client to reset this list by
unblocking all) - or to return an approximation to the privacy list and
add a marker to it, that what a server actually uses might be not
exactly what has been returned. (Modification in XEP-0191)

- Defining an indication, that a privacy list client accepts list
changes for active lists as well. (E.g. as a disco feature of the
client, or an indication a client can pass with his request for the
privacy lists to the server). This will allow blocklists to be modified
if all sessions use block-list clients or privacy-list which support
this feature. (Modification in XEP-0016).

- Define that blocking/unblocking commands my fail because of conflicts.
(I.e. there are sessions neither supporting the updated version of
privacy-lists nor the block-lists.) (Modification in XEP-0191)


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