Subject: P versus Sieve, take 2

From: "Alex Rousskov" <[email-masked]>
Date: Fri, 08 Apr 2005 17:15:36 -0600

Hi,

Here is an informal subjective comparison of Sieve and P, based on a
quick reading of RFC 3028, RFC 3431, and Sieve extension drafts. This
email updates the earlier comparison I did in October 2004.

  	http://www.rfc-editor.org/rfc/rfc3028.txt
  	http://www.rfc-editor.org/rfc/rfc3431.txt
       http://bgp.potaroo.net/ietf/idref/draft-homme-sieve-variables/
	http://www.mvmf.org/docs/draft-daboo-sieve-mime-00.txt

If the group is to make any decision based on this comparison, we
must show it to Sieve people first, for validation. It should be
easier now because there is a Sieve WG.

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

0. Sieve appears to be popular and well supported. Otherwise, IETF
    would not form a WG to update Sieve specifications, right? P does
    not exist yet. This reminds me of an ICAP/OCP situation,
    unfortunately.

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:
    Using Sieve commands in scope would be similar to calling P methods
    or services.

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.

8a. Sieve does not allow for code reuse (i.e., user-defined functions)
    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 reuse, hopefully without significantly increasing vulnerability
    of compliant interpreters.

8b. A Sieve extension allows for computation reuse (i.e., variables).
    Sieve variables are rather ugly and have to obey some wierd rules
    because they were added as an afterthought. For example, if a
    variable is assigned a string that is too long, the variable
    value is silently truncated.
    P variables should be more intuitive and follow normal programming
    practices.

9. Unlike P, Sieve 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. Sieve extensions will provide reasonable access to SMTP message parts,
     but some of those extensions are not well-defined yet. For example,
     http://www.mvmf.org/docs/draft-daboo-sieve-mime-00.txt has expired.
     P delegates providing message part access to the module that defines
     the message object for a given protocol. That module should provide
     full access to all usable message parts.

12. Sieve 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. Sieve supports a simple subset of regular expressions.  We have
    not decided what regular expressions P should support.

14. This item is intentionally left blank.

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 documents quoted above! For more Sieve
documents, see http://www.cyrusoft.com/sieve/documents.html

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

Thank you,

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Sun, 24 Apr 2005 17:55:02 -0400

Folks,

there has been no comment on Alex's analysis, no discussion at all.

It seems that no one is interested in this any more. Should we fold 
the WG? Or fold the "rules language " work item and continue OCP/SMTP? 
But there hasn't been much progrss on this either...

We're far behind with our deliverables. Either we get work done ASAP 
or close shop.

Thanks,
   Markus

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Sun, 24 Apr 2005 17:05:51 -0600

Alex's analysis was orthogonal to what I thought the criteria would
be.  I'd thought Sieve had some advantages in being able to support
SMTP directly; if it does, I can't tell from his comments.  And his
bottom line, about a partially defined language seeming more
attractive than a fully defined language, is a cogent observation.

For me, the requirements are powerful expressions for matching,
easy-to-use variables, and support for parsing network headers.
Also the ability to dispatch to the OPES callout server quickly
and to get replies.

I'd like a narrowly scoped, limited language, because I want to
make it very fast for the OPES matching and dispatching functions.
It has to have a good interface to the underlying OS network
functions.

Failing that, I'll take a general purpose pre-existing language!

So, I'm not thrilled with Sieve, but am willing to work with it, based
on my reading of the drafts last year.  P still seems vague and
undistinguished.

Hilarie

---

From: "Alex Rousskov" <[email-masked]>
Date: Sun, 24 Apr 2005 23:12:34 -0600

On Sun, 2005/04/24 (MDT), <[email-masked]> wrote:

> I'd thought Sieve had some advantages in being able to support
> SMTP directly; if it does, I can't tell from his comments.

Since P can support SMTP directly (whatever that means), this is not a  
difference to base our decision on. Moreover, we should be more concerned  
with support for other protocols because there is no need to invent a new  
language just for SMTP support: Sieve, Milter, etc. are already available.

> make it very fast for the OPES matching and dispatching functions.

I do not think that language scope is directly related to language  
"speed". For example, languages such as C++ have very broad scope but can  
produce programs that are "faster" than programs written in some  
domain-specific languages.

> It has to have a good interface to the underlying OS network

I am not sure why this is necessary, but Sieve does not seem to have  
access to the OS network functions. Such access (as virtually anything  
else) can be added via Sieve extensions.

> Failing that, I'll take a general purpose pre-existing language!

You would still need to define some standard "libraries" or "modules" so  
that people can share high-level configuration files and do not have to  
write low-level code. IMO, using an existing general-purpose language  
would let you avoid defining boring things like math operators, but the  
most challanging work on defining rules-specific interfaces would remain.

Alex.

---

From: jfcm <[email-masked]>
Date: Mon, 25 Apr 2005 23:27:02 +0200

IMHO all this come from the perspective we are mudded into. The initial 
analysis makes (IMHO) the wrong end of the OCP link the core center. To 
clarify this I will note ONES (Open Network Extended Services/Server) 
architecture in which (a network of) servers interoperate services to user 
relations, through shims inserted on the relational paths. What in OPES 
words would mean many OPES calling out the same server.

1. OPES act as a indepedent middle box calling out on external systems.
2. ONES operates services on the user's demand where the user demands it 
(and have located a shim).

OPES are new (similar) logics/RFC every time there is a new applications. 
And have no control/knowledge of the way the callout servers may work.

ONES have a global strategy. They should have a single framework/RFC with 
each application having to provide consistent I/O, and powerful specific 
application management extensions.

OPES cannot permit to deploy a dynamic SMTP strategy depending on a mail 
situation (triggering mail, overload, DoS, etc.). This is a specific 
capability of ONES. What Hilarie describes is typically what a ONES is for 
(with all the versatility to also adapt the filtering strategy to the 
situation). P, Sieve, etc. are different OPES concepts, they are just 
complementary and possibly interactive/complementary shim tools of an ONES.

This is why I ask if we should not document both architectures and report 
to IESG/IAB for further guidance. I think there is room for both, and that 
clarification can only help both.

jfc