[Standards] Blocking command and Privacy Lists

Sam Whited sam at samwhited.com
Mon Dec 22 15:39:49 UTC 2014


On 12/22/2014 08:50 AM, Kurt Zeilenga wrote:
> I would go a bit further… first, I would lift the MUST use a common 
> backend statement and leave implementation details mostly to the 
> implementor.

This would make the behavior very ambiguous if you were using both the
blocking command and privacy lists. I think that if you're using both,
this bit should remain (of course, you could just be using one or the
other, in which case it doesn't matter).

What's really being said here is "ensure that there's a two way mapping
between the default privacy list and the blocklist"... actual backend
storage method is irrelavant (I could store them separately, and just
make sure they both get updated; not sure what the point would be to
that of course, I'm just pointing out the purpose of the statement).

> I would say something like: Where an implementation
> uses a common backend for Privacy Lists and Block Lists, the
> implementation MUST ensure that the blocking behaviors exposed to the
> user are consistent with the semantics of the particular request they
> used manage the information held in that backend as detailed in their
> respective specifications.   This statement in no way alters the
> specified semantics of the requests

In line with the above: "Where an implementation uses both Privacy Lists
and Block Lists with a common backend"...

That's what I've been rapidly moving towards myself. In the discussion
Holger and I have been having out of band, we were tossing around
similar ideas, though more implementation specific.

In summary (if I'm understanding correctly):

If you're using both privacy lists and blocklists, ensure that there is
a direct two way mapping between the two (probably by just using the
same backend datastore), but only if the request follows the exact
semantics of the blocking command (eg. is a block command, or is a
privacy list that matches the block command exactly).
-

—Sam




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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20141222/0465891d/attachment.sig>


More information about the Standards mailing list