Subject: Interaction of encoded-character extension with variables extension

From: Stephan Bosch <[email-masked]>
Date: Fri, 21 Dec 2007 11:56:13 +0100

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
[email-masked]

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Fri, 21 Dec 2007 14:30:07 +0100

> be pretty old already though).

you're right, this is my mistake, I forgot to add text to variables.

> the result of the encoded character substitution.

this was the WG consensus when it was discussed in November 2006.  see
the thread "Invalid syntax to cause runtime error in encoded-character"

> situation result in just "${foobar}" without further substitution.

if you are worried about performance, you byte-compile the script during
upload, and remove the encoded-characters then.

> that you could make this more explicit in the specification.

unfortunately, the variables draft is due to be published.  I guess
we'll have to leave it for the next version when/if it is progressed to
Draft Standard.

-- 
best wishes,
Kjetil T.

---

From: Tony Hansen <[email-masked]>
Date: Sun, 23 Dec 2007 09:48:16 -0500

It would have to be brought out of auth48, but a change to add text
could still be done before it is published without losing the
already-assigned RFC number. It would just not come out of the queue at
the same time as the others (5228 through 5235). Given that RFC-to-be
3889 is still in the RFC editor queue, this is not that unusual a thing.

Is it worth it? This seems like a case that *would* be better done now
rather than in an errata.

If we were to do this, the RFC editor would have to be told quickly so
that they don't go ahead and publish it. Cyrus? Alexey?

Whether is is done now or as an errata, a suggested change is to do this
in section 3.1:

diff rfc5229.txt rfc5229-with-change.txt
*** 143,145 ****
! 3.1.  Quoting
--- 143,145 ----
! 3.1.  Quoting and Encoded Characters

*** 146,148 ****
     The semantics of quoting using backslash are not changed: backslash
!    quoting is resolved before doing variable substitution.
--- 146,150 ----
     The semantics of quoting using backslash are not changed: backslash
!    quoting is resolved before doing variable substitution.  Similarly,
!    encoded character processing is performed before doing variable
!    substitution.

*** 154,155 ****
--- 156,158 ----
                                 expansion of variable foo.
+       "${hex: 24 7B}foo}" => "${foo}" => the expansion of variable foo.

	Tony Hansen
	[email-masked]