Subject: Another Update

From: Markus Hofmann <[email-masked]>
Date: Tue, 19 Oct 2004 20:47:55 -0400

Folks,

we heard from Ted that our new charter proposal was discussed by the 
IESG and no major concerns were raised. It went out for public review 
and will get a second IESG review at the next telechat. Based on this, 
let's get a discussion of the new (proposed) work items going on the 
mailing list.

Tony suggested to have an ananalysis of "P" vs. "Sieve". Anyone any 
thoughts or willing to take a first crack? Why do we need to invent a 
new language when there's already a language that does very similar 
things we want to do for email? Very valid question! [This hopefully 
gets some folks rolling :]

We also need to get a discussion going on SMTP Use Cases - so please 
post to the list of you've some thoughts on that!

Folks - it was quiet for a while. Now that we move forward with the 
new work items, let's get the discussions going again. Only with 
active participants it's worthwhile for us to continue!

-Markus

---

From: Markus Hofmann <[email-masked]>
Date: Thu, 21 Oct 2004 20:48:56 -0400

Folks,

if there is no interest to continue the work with a new charter, we 
should withdraw our new charter proposal and close the WG.

If there's an interest to continue, we need a discussion on this list 
to get the work going. AND - we need folks willing to put in the time 
and effort to drive the work forward.

Thanks,
-Markus

Markus Hofmann wrote:
> Folks - it was quiet for a while. Now that we move forward with the new 
> work items, let's get the discussions going again. Only with active 
> participants it's worthwhile for us to continue!
> 
> -Markus
>

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 21 Oct 2004 22:13:38 -0600 (MDT)

> and effort to drive the work forward.

Markus,

 	I will review Sieve and do a P-versus-Sieve comparison, 
hopefully by Tuesday. Since I am not attending IETF-wide meetings, I do 
not have strong preferences regarding the agenda.

Thanks,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 25 Oct 2004 22:36:39 -0600 (MDT)

Here is an informal subjective comparison of Sieve and P, based on a
quick reading of RFC 3028 and RFC 3431.

 	http://www.rfc-editor.org/rfc/rfc3028.txt
 	http://www.rfc-editor.org/rfc/rfc3431.txt

Note that a few items are related as they look at the same language 
property from different angles.

1. P has a much shorter, easier to spell name.

2. Both languages have similar design goals and execution environment
   as far as email filtering is concerned.

3. P has a much broader scope, including facilitating email adaptation
   (not just filtering) and adaptation of other protocols such as HTTP.

4. Sieve contains commands to redirect or respond to messages. IIRC, P
   scope was limited to directing messages to services (that, in turn,
   could redirect or respond to messages, among other things).  On the
   other hand, if we follow the service-is-a-method approach we have
   discussed, then there may be no difference from user point of view.

5. Sieve scripts are executed during final delivery, when the message
   is moved to the user-accessible mailbox. P can be used during final
   delivery or anywhere message adaptation is needed.

6. P Core makes rich extensions easier, but Sieve was not designed
   with rich extensions in mind (Sieve scope is narrow).

7. If we "extend" Sieve to apply it to HTTP adaptations, we (a) would
   not be able to reuse much and (b) may have to violate a couple of
   existing Sieve Core rules. Thus, the argument "why do we need
   another filtering language?" is not that strong because it is, in
   theory, better to have a single common language for several key
   protocols than multiple similar languages, one for each key
   protocol. It is sad if P/SMTP is Sieve, but one can argue that it is
   not OPES fault that Sieve team did not want to look beyond email
   filtering.

8. Sieve does not allow for code or computation reuse (i.e., functions
   and variables) because creators view reuse as a security model
   violation (not sure why, but it seems to be a common misconception)
   P may allow for some code and computation reuse, hopefully without
   significantly increasing vulnerability of compliant interpreters.

9. Unlike P, 06 does not appear to support modern error handling --
   if something fails, the whole script fails. This might be OK for
   simple/core applications but sounds like a serious limitation if
   non-trivial extension actions are to be supported. It would be
   difficult to write a script that never fails but tries to access
   things deep inside message structure or tries to execute non-trivial
   commands. Even trivial commands like redirecting a message to a
   folder can fail; I am not sure exactly what would happen with
   Sieve-controlled message then; the outcome is likely to be
   implementation-dependent.

10. Sieve has two basic data types: integers and strings. Sieve also
   has lists of strings. For example, MIME headers and even MIME body
   parts are strings. P has many types representing messages and their
   components. Thus, P might support more intuitive, protocol- and
   context-dependent access to data, making some tests faster or more
   precise.

11. I am not positive, but it seems that Sieve provides limited access
   to message parts, assuming some sort of common tests or expressions.
   It seems that some tests may not be possible with Sieve because the
   documented tests hide some details. Perhaps extensions can cover for
   that, or perhaps nobody needs full access to some message parts.

12. 06 does not use XML, but its expression syntax is not
   human-friendly. The assumption is that most scripts will be written
   by programs controlled via user-friendly GUIs.

13. 06 supports a simple subset of regular expressions.  We have
   not decided what regular expressions P should support.

14. 06 Core does not support relational operators other than a
   match (except for message size comparisons?), but extensions such as
   RFC 3431 can add those. I do not know how portable use of extensions
   for operators makes one's code. It is possible that RFC 3431 is
   widely supported so its "extension" status is not an issue.

15. Both languages can require support for a given extension from the
   interpreter (but Sieve scripts cannot recover if such support is
   missing).

16. Sieve does not define a common way to define extensions or load
   extensions into an interpreter. We have argued that P should at
   least provide a way to do the former so that scripts can be
   thoroughly checked against public extension interface, and without
   knowing extension implementation details.

Please correct any factual errors. I am not a Sieve expert or even 
casual user; I just read the two RFCs quoted above! Also, it would be 
great if somebody can describe Sieve popularity in real world. Are we 
looking at a well-established and widely implemented standard? Like 
ICAP?

Finally, I realize that it is easy to portrait partially-defined P in 
a better light than already "frozen" Sieve -- it is easy to claim that
P will gain all necessary features it is missing now.

I would prefer to hear from other folks before sharing my half-baked 
ideas of where this quick comparison leaves us.

Thank you,

Alex.

P.S. I agree with Abbie that to compare we need a set of criteria.
      The above items roughly outline the set I have in my mind. I
      hope the set is visible enough through the details, and I
      hesitate spending a few months on a good criteria document
      instead. This informal approach may backfire, of course.

---

From: "Hilarie Orman" <[email-masked]>
Date: Tue, 26 Oct 2004 01:24:42 -0600

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