[Standards-JIG] block + privacy lists again
mridul at sun.com
Mon Jan 8 19:13:35 UTC 2007
Please see inline.
Peter Saint-Andre wrote:
> Mridul just had a chat about the interaction between block lists and
> privacy lists, which resulted in the following conclusions and questions:
> 1. Modifications to the block list result in changes only to the
> default list and only to the jid+deny items in that list. This means
> that if a privacy list client makes a change to anything except a
> jid+deny item, that change will not be reflected in the block list.
> This also means that if a block list client unblocks an item or
> unblocks all items, that will affect only the jid+deny items in the
> privacy list. The the concept is that the jid+deny entries must be in
> sync between the block list and the default privacy list, but other
> items in the default privacy list are not affected by the block list.
> 2. It's not clear what the priority of blocked (jid+deny) items should
> be in the privacy list. IMHO they should come first in the privacy
> list, but that's only a recommendation, not a requirement.
> 3. Some of this might be easier if we allowed layering of privacy
> lists, as has been discussed in the past. That is, we could have one
> privacy list for jid+deny items and then layer other privacy lists on
> top of that. So that's an item for further discussion.
I was referring to only blocking list layering with privacy list +
rosters though, not arbitrary set of privacy lists :-)
But I guess the idea could be extended or reduced either way.
> 4. If we did invisibility via XEP-0186 and blocking via XEP-0191, how
> many people would really need privacy lists?
> 5. Should we relax the rule in XEP-0016 that says changes to the
> default list MUST be forbidden if the default list is in use by other
> resources? Blocking gets around this by sending updates.
Currently, a roster push has the change also sent across, not just that
the roster was changed : privacy list push on the other hand just say
that the list was modified - that could be modified and this requirement
> Mridul, did I miss anything?
I forgot to mention - named block lists ? Just an idea actually :
Different block lists which are 'named' (same semantics as the current
single list). So client can apply a 'work' or 'home' or 'mobile' block
list based on name.
This might be mapped to different privacy list as impl.
More information about the Standards