[Standards] privacy lists, block lists, and invisibility

Mridul mridul at sun.com
Thu Feb 1 02:25:24 UTC 2007

Peter Saint-Andre wrote:
> It's important for us to admit when we are wrong. And I'm starting to 
> think that we were wrong to develop block lists (XEP-0191). Are 
> privacy lists (XEP-0016) really that complex? Perhaps not, because it 
> seems that they are being added to more and more clients and servers. 
> So do we really need a simplified front-end to privacy lists, i.e., do 
> we really need block lists? Probably not -- especially because it is 
> difficult to correctly specify the interaction between privacy lists 
> and block lists. Furthermore, privacy lists give us flexibility that 
> seems quite helpful in the context of our existing infrastructure, 
> such as the ability to block all contacts who are not in one's roster. 
> By contrast, block lists  only enable one to block based on JabberID, 
> which seems pretty primitive by comparison. Perhaps privacy lists 
> could be simplified a bit to make them easier to implement 
> (suggestions are welcome), but I don't sense a lot of enthusiasm and 
> consensus for XEP-0191, so I am thinking about retracting it.
> However, I do think that XEP-0126 is a misuse of privacy lists for the 
> purpose of invisibility. XEP-0186 feels a lot cleaner to me -- it's a 
> simple "on/off" command and doesn't require complicated manipulation 
> of privacy lists (which should be more stable) for a real-time mode 
> like invisibility/visibility. So I would like to push forward with 
> XEP-0186 so we can finalize, implement, and deploy it.
> Thoughts?
> Peter

  +1 on kicking xep191, though we did do good work to make it in sync 
with xep16 - end of the day, it is just a thin wrapper over xep16 : 
which leads me to next point.
I guess what needs to be done is to make it easier for clients to impl 
privacy lists : some guidelines/impl details would be great on how to 
craft them, manage order, etc.
Maybe extend 16 such that for most of the fast path cases, client does 
not need to bother with managing order, etc : clone a list with 
additions/removals, send diffs for updates, etc.

Regarding invisibility - presence blocking would suffice for some cases, 
but for some others message & iq blocking could also be required.
My nit with126 is that it just mentions presence-out blocking and does 
not talk much about others.
Hence clients tend to ignore this ... they might want to set message/iq 
blocking in cases : to make sure the entity is unreachable from 
some(all) users.
I am not sure about the last para in Impl notes : just use different 
lists instead of editing the same ?


More information about the Standards mailing list