Subject: Re: [Asrg] 4d. Consent Framework - Protocols and Formats - XML-CPDL

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 04 Sep 2003 22:07:19 -0400

At 03:34 PM 8/30/2003, Andrew Akehurst wrote:
>Recently I posted a message on the topic of tests and actions for
>XML-CPDL inspired by those defined by RFC 3028 for Sieve.
>.......

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 

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Andrew Akehurst <[email-masked]>
Date: Fri, 05 Sep 2003 11:33:38 +0100 (BST)

> 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.

Section 5.2 states:

  SIEVE implementations that implement the "spamtest" test 
  have an identifier of "spamtest" for use with the capability
  mechanism.
    
  The "spamtest" test evaluates to true if the spamtest result
  matches the value.  The type of match is specified by the 
  optional match argument, which defaults to ":is" if not
  specified.
    
  The spamtest result is a string starting with a numeric value 
  in the range "0" (zero) through "10", with "0" meaning the
  message is definitely clear of spam, and "10" meaning the 
  message is definitely spam.  The underlying SIEVE 
  implementation will map whatever spam check is done into this
  numeric range, as appropriate.  If the message has not been
  categorised by any spam checking tools, then the spamtest
  result is "NIL".

This would undoubtedly be fine in the context of a single MUA
but it's not readily reusable elsewhere.

The reason is that the terms "underlying SIEVE implementation"
and "as appropriate" involve a certain amount of hand-waving.
It specifies nothing standard about what that underlying
implementation is required to support, nor about how such a
mapping is to be made. 

For example, I could use SpamAssassin on my local system, but
there's no guarantee of what spam tests would be performed
elsewhere nor how those tests would be scored. Since I 
couldn't predict the effects of having the policy enforced 
elsewhere, it would only be useful on my local machine. So 
this Sieve extension may be useful locally but it's no help
for sharing consent policy information.

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/msg07113.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.

Thanks

Andrew

---

From: "Pete - Madscientist" <[email-masked]>
Date: Fri, 5 Sep 2003 10:46:44 -0400

|-----Original Message-----
|From: Andrew Akehurst [mailto:[email-masked]] 
|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