[Gen-art] Gen-ART Last Call Review of draft-ietf-sieve-include-13

Ben Campbell <ben@nostrum.com> Tue, 13 December 2011 22:13 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03C221F8507; Tue, 13 Dec 2011 14:13:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
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 M5LgBACjVwuD; Tue, 13 Dec 2011 14:13:03 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 465AF21F84FB; Tue, 13 Dec 2011 14:13:03 -0800 (PST)
Received: from [10.0.1.2] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id pBDMD0je080107 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Dec 2011 16:13:02 -0600 (CST) (envelope-from ben@nostrum.com)
From: Ben Campbell <ben@nostrum.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 13 Dec 2011 16:13:01 -0600
Message-Id: <E02C28C0-E664-4197-9594-FB12EDA53F1E@nostrum.com>
To: draft-ietf-sieve-include.all@tools.ietf.org
Mime-Version: 1.0 (Apple Message framework v1251.1)
X-Mailer: Apple Mail (2.1251.1)
Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Cc: "gen-art@ietf.org Review Team" <gen-art@ietf.org>, The IETF <ietf@ietf.org>
Subject: [Gen-art] Gen-ART Last Call Review of draft-ietf-sieve-include-13
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Dec 2011 22:13:04 -0000

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may receive.

Document: draft-ietf-sieve-include-13
Reviewer: Ben Campbell
Review Date: 2011-12-13
IETF LC End Date: 2011-12-15

Summary: This draft is almost ready for publication as a proposed standard

Major issues:

None

Minor issues:

-- section 3.1, paragraph 4: "Implementations MUST NOT generate errors for recursive inclusions at upload time, as this would force an upload ordering requirement upon script authors / generators.  However, if an active script is replaced with a faulty script and would remain the active script, an error MUST be generated and the upload MUST fail."

These two statements seem contradictory on a quick reading.  In particular, how can the latter assertion avoid an upload ordering requirement? Or do you mean faulty in some way other than being recursive?

-- section 3.4.1, paragraph 5: "If a "global" command is given the name of a variable that has previously been defined in the immediate script with "set", an error MUST be generated either when the script is uploaded or at execution time."

Does this conflict with the previous statement that it is okay for a global and a private variable to have the same name?

-- section 3.4.2:

Why do you need two ways to accomplish the same thing?

Does the global namespace have the same "requires" requirement as the global command?

-- section 4.2, paragraph 2:

Can you elaborate on what permissions are proper? Is it different for an included script than for any other script?

-- section 4.2, paragraph 3:

Can you elaborate on what you mean by "safe for a storage system"?

Nits/editorial comments:

-- section 3.1, paragraph 4: "authors / generators"

s/ "authors / generators " / "authors and generators"

-- section 3.2, paragraph 9 (Top of page 6): " 
The included script MUST be a valid Sieve script.  Each script MUST
   have its own "require" statements for all optional capabilities used
   by that script. "

Who do these normative statements apply to? As worded, it sounds like they apply to the user. It might be better to say that the implementation MUST validate that…

-- section 3.4.2, paragraph 3: "Variables declared global and variables accessed via the global namespace MUST be one and the same."

Plurality mismatch. I suggest something like "a variable declared as global and a variable accesses with the global namespace, otherwise having the same name…"

-- section 5:

Please explicitly mention the name or URL of the registry table to which this should be added.