ietf-openproxy
[Top] [All Lists]

P versus Sieve, take 2

2005-04-08 16:16:40

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.


<Prev in Thread] Current Thread [Next in Thread>