Re: I-D Action: draft-ietf-sieve-include-11.txt
Aaron Stone <[email protected]>
| Newsgroups | gmane.ietf.mta-filters |
|---|---|
| Message-ID | <CAEdAYKV+Kuys7mFbEJ7eq9YC_tpe02xT=43j2RKjrNaa9tSP2Q@mail.gmail.com> |
On Sat, Sep 24, 2011 at 6:47 AM, Stephan Bosch <[email protected]> wrote: > Hi Aaron, > > Op 23-9-2011 21:20, [email protected] 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 "include" 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 > > > _______________________________________________ sieve mailing list [email protected] https://www.ietf.org/mailman/listinfo/sieve