Subject: yet more changes to Sieve

From: Tim Showalter <[email-masked]>
Date: 24 Feb 1999 03:16:17 -0500

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 <[email-masked]>