[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 16:02:04
I posted -13. Please check if your suggested changes are as you expected.


On Tue, Sep 27, 2011 at 1:50 PM, Robert Burrell Donkin
<robertburrelldonkin(_at_)gmail(_dot_)com> wrote:
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

sieve mailing list

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