Re: P versus Sieve, take 2

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

Alex Rousskov wrote:
> 
> 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.
>