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

Ben Campbell <> Tue, 24 January 2012 21:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDA0A21F85C2; Tue, 24 Jan 2012 13:16:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z4P5vrLvbRZM; Tue, 24 Jan 2012 13:16:19 -0800 (PST)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id 6E76021F85C0; Tue, 24 Jan 2012 13:16:19 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id q0OLGI5w052895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jan 2012 15:16:18 -0600 (CST) (envelope-from
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: multipart/alternative; boundary="Apple-Mail=_78C21AAD-9F65-4D04-A206-7C0FC4E7139D"
From: Ben Campbell <>
In-Reply-To: <>
Date: Tue, 24 Jan 2012 15:16:18 -0600
Message-Id: <>
References: <> <> <>
To: Aaron Stone <>
X-Mailer: Apple Mail (2.1251.1)
Received-SPF: pass ( is authenticated by a trusted mechanism)
Cc: " Review Team" <>, Sieve mailing list <>
Subject: Re: [Gen-art] Gen-ART Last Call Review of draft-ietf-sieve-include-13
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Jan 2012 21:16:28 -0000

Hi Aaron,

Based on discussion and revision 14, I think all my concerns are resolved save one (which I think is pretty much editorial at this point):

On Dec 19, 2011, at 2:46 PM, Ben Campbell wrote:


>> -- 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?
>> It doesn't conflict, because those variables live in separate namespaces. The effect of the global command is to bind the two names. An error is generated rather than specifying if the local overwrites the global value, or the global overwrites the local value.
> I take this to mean you can have a global and a local variable with the same name, but not if they are in the same script, right? If so, then it would help to add that qualification to the 2nd paragraph in 3.4. As it is, it says implementation MUST allow a global and non-global variable to have the same name with no interaction, and doesn't exclude it from happening in the same script.

I think there's still a potential confusion here. If this was addressed in revision 14, I missed it.