On 12/23/2014 08:23 AM, Kurt Zeilenga wrote: > I have don’t see why we’d deprecate something that’s in use simply > because it doesn’t work well with something else in use.
The blocking command bills itself as a frontend for privacy lists [1]. Privacy lists provide a superset of the features offered by the blocking command, however, since some things are using this frontend, and some aren't, it leads to user expectation issues. Similarly, leaving the implementation up to the server administrator, while it sounds fair on first glance, just leads to fragmentation and, again, user expectation failures. Eexpectation management is not, as is often suggested, the responsibility of server and client implementors alone. It's something that needs to be thought of at every level (protocol included). While some of the functionality in privacy lists may be useful, 99% of the time [citation needed] block lists provide all necessary features, and privacy lists are just extra "cruft" (that's a technical term). The way I see it, we owe it to the community to at least reduce the ambiguity of the spec somewhat and make the mappings clear, even if there is opposition to throwing out privacy lists alltogether (though I'm very much a fan of this latter idea). If people *did* want to consider deprecating privacy lists, I think it would be possible to eventually (as we get feedback / see what functionality is actually necessary, etc.) extend the functionality of block lists to include some of privacy list's extra features, instead of just using blocklists as a bandaid for the complexity of privacy lists. Privacy lists try to be a one-size-fits-all solution, which, in my opinion, is *never* a good idea. Best, Sam [1]: http://xmpp.org/extensions/xep-0191.html#privacy -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com
signature.asc
Description: OpenPGP digital signature
