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

I posted -13. Please check if your suggested changes are as you expected.

Thanks,
Aaron


On Tue, Sep 27, 2011 at 1:50 PM, Robert Burrell Donkin
<[email protected]> wrote:
> On Tue, Sep 27, 2011 at 9:36 PM, Barry Leiba <[email protected]>
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/sieve
>
_______________________________________________
sieve mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sieve