On Wed, Sep 30, 2015 at 8:29 AM, Christian Schudt <[email protected]> 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
