Re: Interaction of encoded-character extension with variables extension

[Tony Hansen <[e-mail]>]

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
	[e-mail]

Kjetil Torgrim Homme wrote:
> On Fri, 2007-12-21 at 11:56 +0100, Stephan Bosch wrote:
>> 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).
> 
> you're right, this is my mistake, I forgot to add text to variables.
> 
>> 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 was the WG consensus when it was discussed in November 2006.  see
> the thread "Invalid syntax to cause runtime error in encoded-character"
> 
>> 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.
> 
> if you are worried about performance, you byte-compile the script during
> upload, and remove the encoded-characters then.
> 
>> 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.
> 
> 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.
>