|-----Original Message-----
|From: Andrew Akehurst
[mailto:A(_dot_)D(_dot_)Akehurst-99(_at_)student(_dot_)lboro(_dot_)ac(_dot_)uk]
|Sent: Friday, September 05, 2003 6:34 AM
<snip>
|> Here is a link to an Internet draft defining a spamtest extension for
|> Sieve:
|>
|> http://www.ietf.org/internet-drafts/draft-daboo-sieve-spamtest-03.txt
|
|Thanks Yakov. It's an interesting approach to separating the
|implementation from the policy definition. However I have
|reservations about its ability to be shared between systems in
|a broader consent framework.
I have the same reservations, primarily because the mechanism is largely
procedural rather than declarative. However, it is relatively simple to
see how Sieve as a lanugage can be integrated into the XML-CPDL by
separating the test and action implementations.
I've recently posted a number of test mechanism examples to the example
document. Some of those examples develop a numerical value representing
the "spaminess" of the message under test and this would be compatible
with Sieve.
Once integrated, systems which agree on conventions for tests and
actions using Sieve would then be able to share those poicies in a
declarative way along with other policies that may not use Sieve.
As it turns out though - developing the "common gound" for sharing
policies is a tough problem. The vast majority of examples that are out
there are procedural by nature and therefore very difficult to share
between systems. I think this is an artifact of how current filtering
solutions operate.
Another example, though not necessarily a "procedural/declarative"
problem is the use of pattern matching directly as a TEST. (This is why
none are in the XML-CPDL example yet... I'm still thinking about it).
The problem here is that pattern match tests on a given system are
likely to be very localized in their definition and may not be
applicable in other systems - This may be a "non problem" but in looking
at the examples I can find it does tend to be the case. The direction
I'm leaning on this one right now is that a wide family of tests and
actions are likely to be local to a particular installation or group of
installations and that the XML-CPDL will allow these installations to
share a very deep representation of their policies if the systems agree.
Less compatible system will tend to share only "well known" tests and
actions, and by extension policies. I recommend a focus on expanding the
list of "well known" tests and actions so that we can make this common
ground as broad as possible.
I'll have more thoughts on this later.
|I've been awaiting some feedback on the XML-CPDL tests and
|actions I proposed last week:
|
|
|http://www1.ietf.org/mail-archive/working-|groups/asrg/current/m
|sg07113.html
|
|Does the lack of responses indicate agreement or simply lack
|of interest from members of this list? We need volunteers to
|help move this area forward.
On my part this is mostly a lack of time - not disinterest... and that I
have become distracted by a harder problem - that of identifying the
braodest possible range of tests and actions that can and should be
shared between systems.
I read your note before posting a new range of test examples to the
XML-CPDL example - I think you may find some analogs in there... I will
make a more concerted effort to address your comments directly when I
next revisit test and action examples and language. THANKS FOR THE
INPUT!
_M
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg