Re: Sieve include: interactions with MIME loops

Posting this now.

On Mon, Jan 23, 2012 at 5:00 PM, Ned Freed <[email protected]> wrote:
>> On Sat, Jan 21, 2012 at 5:31 AM, Alexey Melnikov
>> <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/sieve