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
interoperability.
(2.4.2.3) Address comparasons are defined to be case-insensitive on the local
part. (Gregory Sereda has suggested this, and it seems like a very good
idea.)
(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
easier).
(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
failures.
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>