[Top] [All Lists]

Re: [sieve] Clarifying "implementations MUST NOT allow variable expansion in the script name argument" [WAS Re: I-D Action: draft-ietf-sieve-include-12.txt]

2011-09-27 15:50:28
On Tue, Sep 27, 2011 at 9:36 PM, Barry Leiba 
wrote>> When an implementation (of this proposed standard) supporting
encounters a non-constant string, what behaviour is expected?

RFC 5228 section 2.10.6 covers "Errors".
When we say that something MUST happen, and it doesn't, that's an error.
When we say that something MUST NOT happen, and it does, that's an error.
Violations of the base specification and all extensions to it are
already covered in RFC 5226 section 2.10.6.

I regret that we've generally made it a habit to say that violating
this or that or the other thing "MUST generate an error," because
saying that is superfluous... but because we've taken to saying it,
some people clearly expect it, and view the spec as vague when it's
not there.  Nevertheless, the specs are clear, and nothing explicit
needs to be there.  You violate syntax, it's an error.  See RFC 5228
section 2.10.6.

For the record in RFC 5228:

"2.10.6. Errors

   In any programming language, there are compile-time and run-time

   Compile-time errors are ones in syntax that are detectable if a
   syntax check is done.

   Run-time errors are not detectable until the script is run.  This
   includes transient failures like disk full conditions, but also
   includes issues like invalid combinations of actions.

   When an error occurs in a Sieve script, all processing stops.

   Implementations MAY choose to do a full parse, then evaluate the
   script, then do all actions.  Implementations might even go so far as
   to ensure that execution is atomic (either all actions are executed
   or none are executed).

   Other implementations may choose to parse and run at the same time.
   Such implementations are simpler, but have issues with partial
   failure (some actions happen, others don't).

   Implementations MUST perform syntactic, semantic, and run-time checks
   on code that is actually executed.  Implementations MAY perform those
   checks or any part of them on code that is not reached during

   When an error happens, implementations MUST notify the user that an
   error occurred and which actions (if any) were taken, and do an
   implicit keep."

Your interpretation may (or may not) be the consensus of the working
group but nowhere is it clearly and unambiguously set out in that

A high quality specification should clear and simply specify
appropriate behaviour. This draft falls short.

sieve mailing list

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