ietf-openproxy
[Top] [All Lists]

P versus Sieve

2004-10-25 21:36:34


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.


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