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

Stephan Bosch <stephan@rename-it.nl> Mon, 17 October 2011 19:24 UTC

Return-Path: <stephan@rename-it.nl>
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508E321F8CCF for <sieve@ietfa.amsl.com>; Mon, 17 Oct 2011 12:24:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.504
X-Spam-Level:
X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KP3JIygfJAT6 for <sieve@ietfa.amsl.com>; Mon, 17 Oct 2011 12:23:59 -0700 (PDT)
Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id B7CF121F8C93 for <sieve@ietf.org>; Mon, 17 Oct 2011 12:23:58 -0700 (PDT)
Received: from klara.student.utwente.nl ([130.89.162.218]:54648 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <stephan@rename-it.nl>) id 1RFsmv-00073q-0B; Mon, 17 Oct 2011 21:23:54 +0200
Message-ID: <4E9C809D.90808@rename-it.nl>
Date: Mon, 17 Oct 2011 21:23:09 +0200
From: Stephan Bosch <stephan@rename-it.nl>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Aaron Stone <aaron@serendipity.cx>
References: <20110923192026.30531.70942.idtracker@ietfa.amsl.com> <4E7DDF5A.4060505@rename-it.nl> <CAEdAYKV+Kuys7mFbEJ7eq9YC_tpe02xT=43j2RKjrNaa9tSP2Q@mail.gmail.com>
In-Reply-To: <CAEdAYKV+Kuys7mFbEJ7eq9YC_tpe02xT=43j2RKjrNaa9tSP2Q@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-RenameIT-MailScanner-SpamScore: -2.3 (--)
X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1
Cc: Sieve mailing list <sieve@ietf.org>
Subject: Re: [sieve] I-D Action: draft-ietf-sieve-include-11.txt
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group <sieve.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sieve>, <mailto:sieve-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sieve>
List-Post: <mailto:sieve@ietf.org>
List-Help: <mailto:sieve-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sieve>, <mailto:sieve-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Oct 2011 19:24:00 -0000

On 9/27/2011 10:02 PM, Aaron Stone wrote:
> On Sat, Sep 24, 2011 at 6:47 AM, Stephan Bosch<stephan@rename-it.nl>  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.

Regards,

Stephan.