[Standards] XEP-0191 and XEP-0016

Tomasz Sterna tomek at xiaoka.com
Thu Mar 15 21:44:37 UTC 2007

Dnia 15-03-2007, czw o godzinie 15:18 -0600, Peter Saint-Andre
> 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

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?

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?) we could address the issues we have with it
and fix it to get a clean way of doing simple on-off invisibility?

Tomasz Sterna
Xiaoka Grp.  http://www.xiaoka.com/

More information about the Standards mailing list