Re: [Asrg] 4. Consent Framework - General

[Andrew Akehurst <A.D.Akehurst-99@student.lboro.ac.uk>]

Quoting John Fenley <pontifier@hotmail.com>:

> It seems to me that no matter what language the consent famework
> is writen in, the limiting factor is still the tests that can be
> performed. It does no good to have even a perfect consent 
> defenition if the tests that must be perfomed are not possible.

We're obviously limited by the bounds of conventional computation.

If AI technology were good enough I could scan my brain, create a
clone of my mental model for deciding whether e-mail is acceptable
and run that model against incoming messages.

Utterly impractical of course (although Greg Egan gave a nice
fictional description of such a process in "Permutation City").

However there are plenty of tests that are readily computable and
the power of such a framework lies in the ability to logically 
combine tests and to enforce policy decisions at multiple points
in the network.

> I have created a consent framework that i feel is simple, complete,
> and relies on tests that i know would be possible with the 
> choicelist system I have been working on.

Re-reading your PDF at:
  http://www.ftc.gov/bcp/workshops/spam/Supplements/fenley.pdf

... I see Choicelist as being an implementation of a specific 
consent system. (I don't mean that as a criticism of its generality,
just an observation)

The principle behind it is not inconsistent with the ASRG's
definition of a generic consent framework:

   http://www.solidmatrix.com/research/asrg/asrg-consent-framework.html

In that context, the Choicelist consent policy rules specify: 

 - accept mail from Choicelist senders where the user 
   has opted in

 - reject mail from Choicelist senders where the user has
   not opted in

 - filter all other messages using some other spam-filtering
   tools/techniques

Have I interpreted this correctly?

The "Choicelist Database Query Protocol" you refer to at:
  http://www.choicelist.com/Personal.html

... would be a kind of consent protocol as defined in section 2.5
of the ASRG framework.

Choicelist could be one of the implementation options available
in a standard framework, or else could become part of the
standard. If it is as powerful as you suggest then perhaps the
work on XML-CPDL ought to define standard test(s) for checking the
Choicelist status of a sender.

> The attached file would be read as is by a Choicelist MUA.

Thanks, it's worth a read. There's definitely an elegant simplicity
about the way it looks.

First impressions/comments...
  - can you clarify the syntax of the "list" command? In the example
    "list=324bn28v[a][school],3jbnj8bc[a][chemistry class],"

    Is it that "324bn28v" and "3jbnj8bc" are choicelist IDs,
    that "a" is short for "allow" and the other section is a 
    comment or description?

  - in your whitelist/blacklist command entries you specify some
    IP addresses to match against. Which IP address are you 
    intending to match? And how would a Choicelist system
    deal with DHCP or NAT configurations, in which IP addresses
    are either unstable or not those of the machine you expect?

  - consider using ISO 8601 formats on dates. YYYY-MM-DD is less
    ambiguous in an international context than MM/DD/YYYY.

Thanks

Andrew

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg