> Posting this now. Looks good to me. Ned > On Mon, Jan 23, 2012 at 5:00 PM, Ned Freed <ned.freed at mrochek.com> wrote: > >> On Sat, Jan 21, 2012 at 5:31 AM, Alexey Melnikov > >> <alexey.melnikov at isode.com> wrote: > >> > I am looking at the new text in draft-ietf-sieve-include-14.txt: > >> > > >> > 3.5. Interaction with Other Extensions > >> > > >> > When "include" is used with the Editheader extension [RFC5293], any > >> > changes made to headers in a script MUST be propagated both to and > >> > from included scripts. By way of example, if a script deletes one > >> > header and add another, then includes a second script, the included > >> > script MUST NOT see the removed header, and MUST see the added > >> > header. Likewise, if the included script adds or removes a header, > >> > upon returning to the including script, subsequent actions MUST see > >> > the added headers and MUST NOT see the removed headers. > >> > > >> > When "include" is used with the MIME extension [RFC5703] > >> > "foreverypart" control structure, the included script MUST be > >> > presented with the current MIME part as though it were the entire > >> > message. A script SHALL NOT have any special control over the > >> > control structure it was included from. In the MIME example once > >> > again, a "stop" or "return" in an included script cannot directly > >> > terminate or continue flow of a "foreverypart" block. In such a > >> > case, the included script should set a global variable that the > >> > including script can test. > >> > > >> > This makes me think that it is not clear what effect the "reject" action > >> > would have if called in an included script within a "foreverypart" block. > >> > What does it mean to "reject" a particular body part of a message? > > > >> I think it should immediately halt the script chain and reject the > >> entire message. > > > > I don't agree; I think it should simply set reject as the script result > > and continue. It's possible that some other action that's compatible with > > reject (e.g., notify) would be done later. If you want it to halt you > > can put stop after the reject. > > > >> I think stop does the same, except with the implicit > >> keep as the default. > > > > Right, but stop should be the only thing that terminates execution. > > > >> Some text in an additional "interactions with other extensions" > >> subsection should state this. > > > >> Oh man, here goes another rev. > > > > Good thing they're cheap. > > > > Ned > _______________________________________________ > sieve mailing list > sieve at ietf.org > https://www.ietf.org/mailman/listinfo/sieve
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.