Alex,
good work, thanks.
I agree with you final remarks.
Hilarie, I also agree with your feedback.
It seems to me that P should be inspired by Sieve.
Agree with Alex, need to understand how Sieve is accpeted (limitations and
Plusses)
in the IT world.
Abbie
-----Original Message-----
From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of
Hilarie Orman
Sent: Tuesday, October 26, 2004 3:25 AM
To: 'Alex Rousskov'
Cc: 'OPES Group'
Subject: RE: P versus Sieve
A good summary, thanks for doing it.
Sieve seems to have a good handle on designating the basic
attributes of email messages, and I think it will be
important to ensure that P can do all that Sieve can with
similar economy of notation. Does Sieve have a logical pathway to
other protocols? I'm not sure ... I guess it arguably
handles any protocol with the format "header: parameters".
It might be tricky to extend the language to handle
mime subparts (because they have to be parsed recursively,
and the language is not recursive). What about
"sizeof(part)>10K"? Or "one of the received from headers is
from IP addr 66.118.143.1"?
Sieve's intention of providing provably terminating and safe
filtering rules could give us ideas for additional goals for
P. We might like to classify actions into safety categories.
We expect P to have an extensible set of actions, but not all
actions are guaranteed to be safe, in that they might not
terminate or might increase the message size greatly). So, P
might have "safety labels" on actions, and users might need
special privileges to use less-than-perfectly-safe actions.
Hilarie