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

From: Robert Burrell Donkin <[email-masked]>
Date: Tue, 27 Sep 2011 20:22:47 +0100

On Sat, Sep 24, 2011 at 7:37 PM, Barry Leiba <[email-masked]> wrote:
> I'm going to hold off on sending this version to Pete until Robert's
> and Stephan's notes are responded to and we've resolved what we're
> going to do (or not) about those.

And one more :-)

draft-ietf-sieve-include-12 specifies:

"implementations MUST NOT allow variable expansion in the script name argument"

A clear specification should unambiguously describe the expected
behaviour. I would therefore prefer something tighter, either [1] or
[2] (or something else if I've guessed the intended meaning wrong).

Robert

[1] "Implementations supporting VARIABLES [RFC5229] MUST NOT expand
variables in the script name argument."
[2] "Implementations supporting VARIABLES [RFC5229] MUST terminate
execution by raising an error unless the script name argument is a
constant string as defined in VARIABLES [RFC5229], Section 3."

---

From: Aaron Stone <[email-masked]>
Date: Tue, 27 Sep 2011 13:10:46 -0700

The full sentence is:

187           The script name argument MUST be a constant string as
188           defined in <xref target='RFC5229'>VARIABLES</xref>, Section 3;
189           implementations MUST NOT allow variable expansion in the script
190           name argument.

I believe that this is sufficient, bordering on repeating itself.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 27 Sep 2011 16:12:13 -0400

> I believe that this is sufficient, bordering on repeating itself.

I agree; I see no reason to change that text.

Barry

---

From: Robert Burrell Donkin <[email-masked]>
Date: Tue, 27 Sep 2011 21:24:21 +0100

>> I believe that this is sufficient, bordering on repeating itself.

When an implementation (of this proposed standard) supporting RFC5229
encounters a non-constant string, what behaviour is expected?

> I agree; I see no reason to change that text.

Which perhaps explains the poor quality of recent output of this
working group...

Robert

---

From: Barry Leiba <[email-masked]>
Date: Tue, 27 Sep 2011 16:28:22 -0400

> Which perhaps explains the poor quality of recent output of this

Insults will definitely bring you credibility, yes.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Tue, 27 Sep 2011 16:36:12 -0400

> 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.

Barry

---

From: Robert Burrell Donkin <[email-masked]>
Date: Tue, 27 Sep 2011 21:36:34 +0100

> Insults will definitely bring you credibility, yes.

At least provocative statements are answered prompted and directly :-)

Sadly in marked contrast to the the questions I asked

Robert

---

From: Robert Burrell Donkin <[email-masked]>
Date: Tue, 27 Sep 2011 21:50:24 +0100

On Tue, Sep 27, 2011 at 9:36 PM, Barry Leiba <[email-masked]>
wrote>> When an implementation (of this proposed standard) supporting
RFC5229
> needs to be there.  You violate syntax, it's an error.  See RFC 5228

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

---

From: Aaron Stone <[email-masked]>
Date: Tue, 27 Sep 2011 14:01:35 -0700

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-masked]> wrote:
> _______________________________________________
> sieve mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sieve
>