[Standards] Blocking command and Privacy Lists
sam at samwhited.com
Tue Dec 23 13:58:17 UTC 2014
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 .
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  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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the Standards