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

Stephan Bosch <stephan@rename-it.nl> Sat, 24 September 2011 13:44 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 1208A21F8B25 for <sieve@ietfa.amsl.com>; Sat, 24 Sep 2011 06:44:47 -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 ZePUMC0-I-bv for <sieve@ietfa.amsl.com>; Sat, 24 Sep 2011 06:44:46 -0700 (PDT)
Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id 4801E21F8B20 for <sieve@ietf.org>; Sat, 24 Sep 2011 06:44:44 -0700 (PDT)
Received: from ip565f7a5d.direct-adsl.nl ([86.95.122.93]:50126 helo=[192.168.1.73]) 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 1R7SZW-0004Wx-VZ; Sat, 24 Sep 2011 15:47:18 +0200
Message-ID: <4E7DDF5A.4060505@rename-it.nl>
Date: Sat, 24 Sep 2011 15:47:06 +0200
From: Stephan Bosch <stephan@rename-it.nl>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Sieve mailing list <sieve@ietf.org>
References: <20110923192026.30531.70942.idtracker@ietfa.amsl.com>
In-Reply-To: <20110923192026.30531.70942.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="UTF-8"; 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
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: Sat, 24 Sep 2011 13:44:47 -0000

Hi Aaron,

Op 23-9-2011 21:20, internet-drafts@ietf.org 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 &quot;include&quot; 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.

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.



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.

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