Quoting John Fenley <pontifier(_at_)hotmail(_dot_)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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg