[Standards] Deprecating Privacy Lists

Sam Whited sam at samwhited.com
Wed Sep 30 13:59:30 UTC 2015


On Wed, Sep 30, 2015 at 8:29 AM, Christian Schudt
<christian.schudt at gmx.de> wrote:
> IMO, it's not a client interop issue, but a server mapping issue and a lack of well specified mapping rules.

The problem is that privacy lists is almost too flexible, making it
both difficult to implement, and difficult to create that server side
mapping. Eg. you might map only action='deny', but then a client may
choose to block only a subset of stanzas from a client (maybe it still
wants to receive presence updates) using privacy lists. The server
won't see that as "blocked". It only works when all clients use the
exact same behavior for "blocked" (a behavior that must exactly match
that described in the Blocking Command XEP).

Having two specs that do roughly the same thing (or one doing a
superset of the other) will always cause client interop issues, and it
certainly does here. Work arounds on the server side can only get you
so far. Specifying the mapping rules would definitely work better, and
possibly mandating that clients MUST use those mapping rules if they
provide a simple "block" interface, but I suspect that that will only
uncover another little issue in which the two don't work so well
together.

—Sam


-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com


More information about the Standards mailing list