Interaction of encoded-character extension with variables extension

Stephan Bosch <stephan@rename-it.nl> Fri, 21 December 2007 11:08 UTC

Return-path: <owner-ietf-mta-filters@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5fjh-0008EI-HK for sieve-archive-Aet6aiqu@lists.ietf.org; Fri, 21 Dec 2007 06:08:13 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5fjf-0004qT-Tl for sieve-archive-Aet6aiqu@lists.ietf.org; Fri, 21 Dec 2007 06:08:13 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBLAuXTO018021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Dec 2007 03:56:33 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBLAuXYq018020; Fri, 21 Dec 2007 03:56:33 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f
Received: from cola.rename-it.nl (cola.rename-it.nl [217.119.231.192]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBLAuUju018008 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-mta-filters@imc.org>; Fri, 21 Dec 2007 03:56:32 -0700 (MST) (envelope-from stephan@rename-it.nl)
Received: from klara.student.utwente.nl ([130.89.162.218] helo=[10.168.3.2]) by cola.rename-it.nl with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <stephan@rename-it.nl>) id 1J5fQY-0001TG-5W for ietf-mta-filters@imc.org; Fri, 21 Dec 2007 11:48:26 +0100
Message-ID: <476B9BCD.80300@rename-it.nl>
Date: Fri, 21 Dec 2007 11:56:13 +0100
From: Stephan Bosch <stephan@rename-it.nl>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: SIEVE <ietf-mta-filters@imc.org>
Subject: Interaction of encoded-character extension with variables extension
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-RenameIT-MailScanner-VirusScan: Found to be clean
X-RenameIT-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.843, required 5, autolearn=not spam, ALL_TRUSTED -0.40, AWL 0.16, BAYES_00 -2.60)
X-RenameIT-MailScanner-From: stephan@rename-it.nl
X-Spam-Status: No
Sender: owner-ietf-mta-filters@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb

Hello,

I am building a Sieve implementation and, while reading the new 3028bis 
specification, I noticed the new encoded-character extension. Its 
substitution syntax is somewhat similar to what the variables extension 
defined ( i.e. ${....} ). I am currently working with 
draft-ietf-sieve-3028bis-13 and draft-ietf-sieve-variables-08. Now I am 
wondering how these extensions are supposed to work if both are active. 
Niether specification mentions this possibility (variables-08 seems to 
be pretty old already though).

One could define encoded-character substituion to be performed before 
any variables substitution, making the variables substitution act upon 
the result of the encoded character substitution. This would make the 
following possible:

"${hex: 24 7B}foobar}"  ==> "${foobar}" ==> "Whatever the foobar 
variable holds."

Although this is (to my opinion) intuitively the most logical 
implementation, I can imagine other options in which encoded character 
and variables substituion is performed in parallel, making use of the 
fact that both extensions use the same delimiters for marking a 
substitution. This could make things more efficient, as only one pass is 
needed to identify substitutions in the string. This makes the above 
situation result in just "${foobar}" without further substitution. 
Although the above example is pretty useless and very unlikely to occur 
in reality, I think it is appropriate for a specification to explicitly 
note what is to be done in this situation.

Note that I am not trying to revive any old discussion on this topic. I 
would just like to know what your opion is on this issue and I am hoping 
that you could make this more explicit in the specification.

Regards,

--
Stephan Bosch
stephan@rename-it.nl