Re: [sieve] I-D Action: draft-ietf-sieve-include-11.txt

[Aaron Stone <[e-mail]>]

On Sat, Sep 24, 2011 at 6:47 AM, Stephan Bosch <[e-mail]> wrote:
> Hi Aaron,
>
> Op 23-9-2011 21:20, [e-mail] schreef:
>>
>>  A New Internet-Draft is available from the on-line Internet-Drafts
>>  directories. This draft is a work item of the Sieve Mail Filtering
>>  Language Working Group of the IETF.
>>
>>  Title : Sieve Email Filtering: Include Extension Author(s)
>>  : Cyrus Daboo Aaron Stone Filename :
>>  draft-ietf-sieve-include-11.txt Pages : 15 Date
>>  : 2011-09-23
>>
>>  The Sieve Email Filtering &quot;include&quot; extension permits users
>>  to include one Sieve script inside another. This can make managing
>>  large scripts or multiple sets of scripts much easier, and allows a
>>  site and its users to build up libraries of scripts. Users are able
>>  to include their own personal scripts or site-wide scripts.
>
>
> You missed one issue I mentioned earlier: the paragraph about the
> application of the :once parameter starting at the end of page 5 and
> continuing on page 6 should be located directly below the description of the
> :once parameter and not below the paragraph describing :optional. So, it
> should  be moved one paragraph up.

Got it.

> A small editorial nit:
>
> The "spam_checks" example on page 10 has a require statement starting in the
> wrong text column and the global command that follows should be on the next
> line.

Fixed.

> Finally, I'd like to share a few things I only notice now because I've
> recently read RFC 5703 (mime extensions) once more. On page 6 of the include
> draft the following is mentioned:
>
>   The "include" command MAY appear anywhere in a script where a control
>   structure is legal, and MAY be used within another control structure,
>   e.g., within an "if" or "foreverypart" block (MIME [RFC5703]).
>
> So, from this I understand that the foreverypart context is passed down to
> any script included while in this context. This means that the behavior of
> the :mime-augmented tests in the included scripts is influenced accordingly.

I don't see why the context would be passed along, but I'll note
explicitly that it is not:

OLD:
255           The "include" command MAY appear anywhere in a script where a
256           control structure is legal, and MAY be used within another control
257           structure, e.g., within an "if" or "foreverypart" block
(<xref target='RFC5703'>MIME</xref>).

NEW:
255           The "include" command MAY appear anywhere in a script where a
256           control structure is legal, and MAY be used within another control
257           structure, e.g., within an "if" or "foreverypart" block
(<xref target='RFC5703'>MIME</xref>).
258           The included script SHALL NOT have any special control over the
259           control structure it was included from, e.g., inclusion
from within a
260           "foreverypart" block does not allow the included script
to directly
261           terminate or continue flow of that block.


> Now I was wondering what would happen when a top-level "break" action is
> executed in a script included somewhere in context of the foreverypart loop,
> or - equivalently - a break statement with name parameter equal to that of
> the foreverypart command in the including script. Initially, I feared this
> would require ending the included scripts and "return"-ing to the script
> executing the loop (at the position of the loop's end).  However, on page 6
> of the include draft the following is stated:
>
>   The included script MUST be a valid Sieve script.
>
> In light of the "break" issue, I like to read this as follows:
>
>   The included script MUST be a valid Sieve script in its own right.
>
> Since it is not allowed to have a "break" action outside a foreverypart loop
> or a break statement referencing a named loop that does not exist, an
> included script with such a break statement is invalid because it is not a
> valid Sieve script in its own right, i.e. without the foreverypart loop of
> the including script. This nicely prevents having break statements that
> cross include boundaries.
>
> Do you agree with this view on the matter? Is some more explicit mention of
> the interaction between foreverypart and include necessary?
>
>
> Regards,
>
> Stephan
>
>
>