[Top] [All Lists]

yet more changes to Sieve

1999-02-24 01:11:16
This is a list of places where in my most recent review of the Sieve
spec, I found problems.  I'd like to make these changes; I may not make
them by Friday.

I hope I'm not starting to cover old ground here; some of the error
discussion feels that way to me, but I believe it's important for

( Address comparasons are defined to be case-insensitive on the local
part.  (Gregory Sereda has suggested this, and it seems like a very good

(2.4.2) Backslashes always disable magic semantics of a character, even if it
has none.  This prohibits backslashes to make characters magic.  This is no
real change to the existing specs but may change extensions.  This is what
CMU's implementation implements (because it doesn't matter now and it was

(2.10.4) This section is meant to provide limits on some actions.  I propose
the removal of redundant text in the Security Considerations section (to be
replaced with a reference to this section), along text implying the following:

Sites get to establish limits on numbers of actions.  If users go over the
limits, it is not an error, and the actions listed in the script first count.
Zero is not an allowed limit.

The maximum number of rejects that a script is allowed to perform on a single
message is one.

(Following from this, the maximum number of vacations to be excuted by a
single script running on a single message is one.)

There is probably need for more text here.

(2.10.6, new section) We need some discussion of error handling to at least
define what "error" means in the draft.  I know some of this was chalked 
up as quality-of-implementation issues, but we haven't laid down ground
rules for bare minimums.  I suggest the following text.

        For the purposes of this memo, there are two kinds of errors,
        compile-time and run-time.

        Run-time errors arise when an implementation actually tries to run an
        action: the user is over quota, too many of a given action are taken,
        too many actions are taken on a single message, etc.

        Compile-time errors are those that are detected during parsing.  The
        label "compile-time" is descriptive, but inaccurate, as most
        implementations are not expected to actually compile scripts to
        machine or byte code.

        While implementations are certainly allowed to perform atomic
        operations such that in the case of a run-time error, no actions
        are taken, they are not required to do so.  It is expected that
        in the case of run-time errors, implementations may have partial 

        Implementations are permitted to detect compile-time errors until they 
        actually encounter a syntax error or an unrecognized require.
        Implementations may execute actions while evaluating the script.
        However, in the event of an error, implementations MUST abort out at
        the first oppertunity.

        In the case of any error, the equivalent of a "keep" action
        happens to ensure that the message is delivered to someone.

        The above is very permissive.  Implementations are encouraged to
        detect errors as early as possible and inform users that something has
        gone wrong.  It is better to do a full parse before executing the
        script, but it is not required.

Tim Showalter <tjs+(_at_)andrew(_dot_)cmu(_dot_)edu>

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