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

From: Aaron Stone <[email-masked]>
Date: Mon, 19 Dec 2011 09:04:38 -0800

On Mon, Oct 17, 2011 at 12:23 PM, Stephan Bosch <[email-masked]>wrote:

> On 9/27/2011 10:02 PM, Aaron Stone wrote:
>
>> On Sat, Sep 24, 2011 at 6:47 AM, Stephan Bosch<[email-masked]>
>>  wrote:
>>
>>> 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.
>>
>
> I've been pondering on this a little while. As it is now, this only solves
> part of the ambiguity imho. For instance in RFC 5703 Section 4.1 the
> following alternatives (amongst others) are described:
>
>   When used outside the context of a "foreverypart" iterator, and with
>   an ":anychild" tagged argument, the "header" test will examine all
>   MIME body parts and return true if any of them satisfies the test.
>
>   When used inside the context of a "foreverypart" iterator, and with
>   an ":anychild" tagged argument, the "header" test will examine the
>   current MIME part context and all its nested MIME body parts,
>   returning true if any of them satisfies the test.
>
> So, imagine the following situation.
>
> <toplevel>
> require "foreverypart";
> require "include";
>
> foreverypart {
>  if :mime :anychild "subject" "whatever" {
>     include "included";
>  }
> }
> </toplevel>
>
> <included>
> require "mime";
> require "fileinto";
>
> if header :mime :anychild :contenttype "Content-Type" "text/html"
> {
>  fileinto "INBOX.html";
> }
> </included>
>
> So, what does this do? Which of the two alternatives described above is
> used? Is the header test in the "included" script executed in the context
> of "foreverypart" in the "toplevel" script or not, i.e. is the foreverypart
> context passed down to included scripts? In my opinion, this is still bit
> ambiguous in the current wording. From your reply I infer that the context
> is not passed down, but perhaps the text should mention that explicitly. It
> is not only about the influence the includED script may have on the loop in
> the includING script, but also about the influence in the other direction.
>
>
My apologies for such a delayed reply. It took me a minute to get what you
were saying here -- you're correct that I was caught on the impact of the
included script on the including script, and I missed the question of
whether the including script can essentially set the scope of what the
included script sees as "the message" to actually be some inner MIME part,
without seeing the entire containing message.

I could see this being useful, and either way could be somewhat confusing
depending on what the user wants to do.

I was originally going to say, "no way, context is bad" but here are my two
arguments in favor of context:

RFC 5703 MIME Loops: I don't see a way to specify which MIME part another
piece of code should look at, which is kind of a bummer. Script A would not
be able to find some interesting mime part and then include script B with a
variable like "global.mime_part_to_look_at", where script B then grabs just
that part and does some useful transformation on it. So if you have a
script that makes a specific transformation, you have to set the context,
then call the script within that context.

RFC 5293 Edit Header: If a message is edited, it's edited. An included
script should see the edited message, not the original message. That means
the language already has some concept of context.

This may require a little bit of discussion! Anybody agree / disagree?

Aaron