[sieve] Variable expansion issues
Hannah Schroeter <hannah@schlund.de> Tue, 06 October 2009 15:54 UTC
Return-Path: <hannah@schlund.de>
X-Original-To: sieve@core3.amsl.com
Delivered-To: sieve@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8621528C1D5 for <sieve@core3.amsl.com>; Tue, 6 Oct 2009 08:54:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.523
X-Spam-Level:
X-Spam-Status: No, score=-5.523 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtiLbxBsqWKE for <sieve@core3.amsl.com>; Tue, 6 Oct 2009 08:54:14 -0700 (PDT)
Received: from mxintern.schlund.de (mxintern.schlund.de [212.227.126.205]) by core3.amsl.com (Postfix) with ESMTP id 2BDFB28C1DC for <sieve@ietf.org>; Tue, 6 Oct 2009 08:53:53 -0700 (PDT)
Received: from [172.19.16.7] (helo=home.kundenserver.de) by mxintern.schlund.de with esmtp (envelope-from <hannah@schlund.de>) id 1MvCNu-0000iJ-8Y for sieve@ietf.org; Tue, 06 Oct 2009 17:55:30 +0200
Received: from hannah by home.kundenserver.de with local (Exim 3.36 #1) id 1MvCNu-0004Vo-00 for sieve@ietf.org; Tue, 06 Oct 2009 17:55:30 +0200
Date: Tue, 06 Oct 2009 17:55:30 +0200
From: Hannah Schroeter <hannah@schlund.de>
To: sieve@ietf.org
Message-ID: <20091006155529.GB30158@schlund.de>
Mail-Followup-To: sieve@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Organization: Schlund + Partner AG
X-Virus-Scanned: Symantec AntiVirus Scan Engine
X-UI-Msg-Verification: fd7691170ce6f0538e97445915a70bb5
Subject: [sieve] Variable expansion issues
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIEVE Working Group <sieve.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 06 Oct 2009 15:54:15 -0000
Hello! I've read the recent mails. I agree to the general gist that it's best to specify once and for all in the variables extension (RFC 5229) that variables expand in every string position unless explicitly specified otherwise and that additional ABNF-like language in the other specifications means restrictions on the string result *after* variable expansion. However, there are a few places where I would like/have liked such an explicitly stated restriction on variable expansion. The variables extension (RFC 5229) *does* specify such a restriction on require (though a bit indirectly: "The require clauses themselves are not affected by this extension.", first paragraph in section 1, it'd be more explicit if the language using the term "constant string" would've been used on "require", too), and on "set" (section 4, "The name MUST be a constant string"). I'd think, then, it'd be logically consequential to require *constant* strings in other places where variable *names* are used, such as in - Imap4flags (RFC 5232), * The hasflag test (unlike the "string" test it doesn't use interpolation but a variable name itself). I do *not* mean "list-of-flags", but "variable-list". * The setflag, addflag, removeflag actions (section 3.1 through 3.3), parameter "variablename" (I don't mean to talk about "list-of-flags"!). Here, "variablename" is just like "name" in the "set" action in RFC 5229, and "name" for "set" is required to be constant. It'd be non-consequential to allow variable names be given by other variables here, when RFC 5229 just does *not* allow that (indirect variable references). - Similarly: draft-ietf-sieve-mime-loop-09.txt, * The "varname" parameter of the "extracttext" action isn't specified to be constant there. The same argument applies though. This especially makes sense as the use of constant strings in "set" and not allowing indirect variable references in the interpolation syntax allows for statical analysis of how many and which variables are used. That is thwarted if one allows other extensions to use variables in variable *names*. I think there those changes would be virtually necessary. The other way of consistency would be to drop the restriction on "set" and to allow indirect variable references on interpolation, too, e.g. "${x_${bar}}", but then enforcing limits on the number on variables used must be deferred to run-time generally. In fact there are other places where at least *I* would rather like *constant* strings (or even tags) to be used, like the match types of the relational extension. (And in fact, the ABNF there *did* suggest constant strings to me!) IMO, variables don't really buy you much there and it just adds unneeded complexity to a Sieve engine that translates the script (from a simple enumeration [e.g. C-style enum] of match types to a much more complex data type, using a combination of an enumeration [basic match types] and a Sieve string, but the latter only sometimes). Kind regards, Hannah.
- [sieve] Variable expansion issues Hannah Schroeter
- Re: [sieve] Variable expansion issues NED+mta-filters
- Re: [sieve] Variable expansion issues Stephan Bosch
- Re: [sieve] Variable expansion issues NED+mta-filters