[Standards] XEP-0191 and XEP-0016

Peter Saint-Andre stpeter at jabber.org
Fri Mar 16 17:58:58 UTC 2007

Tomasz Sterna wrote:
> Dnia 15-03-2007, czw o godzinie 15:18 -0600, Peter Saint-Andre
> napisał(a):
>> OK, folks, make up your minds. We had all sorts of complaints that 
>> "privacy lists are too hard", therefore I wrote up XEP-0191. So my 
>> question is: are they complex or not? If not, I would be happy to 
>> retract XEP-0191 and we can move forward with XEP-0016 alone.
> My feeling is, that XEP-0191 is a result of lack of the consensus on how
> would we define simpler "subset-protocol" on top of XEP-0016. Neither as
> extensions nor as recommendations.
> There is one thing I like very much in XEP-0191.
> "If a service deploys both privacy lists and simple communications
> blocking, the service MUST use the same back-end data store for both
> protocols."

And the one thing people *don't* like is the lack of notifications about 
changes to privacy lists, which are in XEP-0191 but not in XEP-0016. So 
those features need to be synced up, I think.

Another failing seems to be the inability to modify a list if it is in 
use, but notifications might solve that problem.

Some people want "layers" too, so that you could have things like a 
corporate privacy list and on top of that a user-defined privacy list, 
so that may be something we want to discuss as well.

> Isn't this the very heart of what this XEP-0191 is about?
> We do like the XEP-0016 but we want to have a simpler semantics for the
> ones that do not need the full power of Privacy Lists.
> It's like the PEP and PubSub case. And we managed to get it going.
> Shouldn't we follow the same road here?

Quite possibly, yes. :)

> Let's leave Privacy Lists for the ones that needs them and integrate
> simple layer on top of it, that just sets simple blocking, without all
> the hassle of managing full lists client side.
> And once we have extracted Privacy to XEP-0016 (is there an intention to
> remove it from RFC3921bis?) 

It already has been removed from rfc3921bis:


> we could address the issues we have with it
> and fix it to get a clean way of doing simple on-off invisibility?

I still don't think that privacy lists are the right place to do simple 
on-off invisibility. The volume of modifications to the privacy list 
concerns me.


Peter Saint-Andre
XMPP Standards Foundation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070316/d07b4353/attachment.bin>

More information about the Standards mailing list