Quoting Pete - Madscientist <madscientist(_at_)microneil(_dot_)com>:
|>The XML-CPDL is _somewhat_ agnostic on the application of SCOPE, but
|>fairly definite on it's implementation. I think at the very least we
|>should be sure that SCOPE as defined in the consent framework is not
|>incompatible with the XML-CPDL. We should probably endeavor to make a
|>direct linkage between the two - and where that is not
|possible explain
|>how the two interact.
|
|The languages and protocols for consent should flow out from
|the consent
|framework. This is consistent with the approach taken by the
|IM WG in the IETF.
Since we are here to develop both the framework and languages that
express that framework I have the expectation that there is room for
movement in both. Where that is not the case there is bound to be
conflict since implementation constraints seldom match the more
academic constraints of "a given framework". Some compromise is
always present for practicality sake.
I would hope that since both aspects are present in the work of this
group that any such conflicts could be minimized as a matter of course
resulting in a better overall product - reflected both in the
framework, and the suggested implementations...
This seems reasonable enough. The two are closely related and the
development of one can help to improve the other.
Incidentally, while we're on the topic of the consent language, I
stumbled across RFC 3028 again today:
http://www.ietf.org/rfc/rfc3028.txt
For those not familiar with it, it's for a mail filtering language
known as Sieve.
Kee Hinkley and a few others have mentioned this before:
https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg02001.html
Although it's not an XML-based syntax its sections 4 and 5 define
some tests and actions which might be useful inspiration for the
basic "primitives" which we discussed before as a way of providing
a minimum consent policy.
Sieve is designed for use at the MUA or final-MTA level, so it is
written from that point of view. Not all of its features may be
appropriate for use in an MTA but nonetheless I'll point out some
of the interesting ones:
The basic tests in Sieve are:
- test an address to see if it matches a certain pattern
- test a header to see if it matches a certain pattern
- test header to see if a certain header exists: this could be
used to check for the presence of CRI headers, for example
- test size of message to see if it's in a certain range
There are also "allof", "anyof" and "not" tests which can be used
to group tests, the first two obviously correspond to logical
conjunction (AND) and disjunction (OR) respectively. You could
create corresponding "<AND>" / "<ALLOF>", "<OR>" / "<ANYOF>" and
"<NOT>" elements to express such structures in XML.
The above tests are very simple and won't do much on their own.
Which is why I'd like to take them as basics and try to create
some additional, more powerful, tests to go alongside them.
I'm leaving out the precise syntactical details such as the
types of comparator used so as not to confuse the issue with
too much Sieve syntax. But the idea of combining tests in this
way is something that the <CONDITIONS> element of the XML-CPDL
could do with:
http://www.sortmonster.com/ASRG/ConsentPolicyExample.xml
As for actions, the basic actions in Sieve are:
- reject (bounce the message back with an error e-mail)
- fileinto (store the message in a specific mailbox folder - not
really meaningful outside of a MUA)
- redirect (forward the message elsewhere, subject to loop
detection of course)
- keep (allow the message to arrive in the inbox)
- discard (silently delete the message with no bounce)
These types of things would make good <ACTION> options.
I would suggest that these items are (semantically) a good
starting point for things which ought to be in our consent
language.
You could even use Sieve as a basis for defining extensions
to the basic language as it's intended to be extensible. For
example, RFC 3431 defines some relational >= and <= comparators
for use therein (http://www.ietf.org/rfc/rfc3431.txt).
Of course Sieve has no XML syntax so it doesn't sit very
neatly with our language as-is. However people might choose
to use a Sieve engine or SPITBOL or whatever they like to
implement their own tests/actions as you suggest.
I'd still like to clarify where the dividing line should be
between the standard policy language and any extensions but
I'm sure that as we develop the XML-CPDL primitives it will
become clear what won't actually be part of the standard.
The first step would be to render the above into some sensible
XML and see how it looks.
Any comments?
Andrew
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg