On Tue, Sep 27, 2011 at 9:36 PM, Barry Leiba
<barryleiba(_at_)computer(_dot_)org>
wrote>> When an implementation (of this proposed standard) supporting
RFC5229
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
errors.
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
execution.
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
section.
A high quality specification should clear and simply specify
appropriate behaviour. This draft falls short.
Robert
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve