Ned Freed wrote:
[...]
I have to agree with Michael - changing the basic syntax of sieve is
unacceptable.
>I don't think the base spec allows that.
>
IMHO, if it explicitly prohibit such change, we need to change the base
spec.
One of the key strengths of sieve is that the core syntax is both simple
and immutable. This makes it possible to perform syntax checks even if
you don't understand all the extensions a given script uses. Breaking
this would IMO be hugely damaging.
Ok, good point.
>Sieve has a very
>small syntax, moving most stuff to the semantical layer for being very
>extensible, pretty much like LISP does.
>
>The variables extension, for example, introduces the concept of
expanding
>strings, but only at the semantic level. Syntactically, strings still
>look the same.
The problem is that RFC 3028 said that '\ <octet>' for any <octet> other
than <\> or <"> SHOULD be interpreted as <octet>.
This effectively means that we can't fix quoted strings. So I had to
introduced a new quoted string.
First of all, having an extension that changes the interpretation of,
say, \x
followed by two hex digits would IMO be far less damaging than an
extension
that changes the core syntax.
Fair enough.
Do you have any better suggestions?
There are all sorts of ways to do it. Here's an obvious one: If the
octet-value extension is enabled, any occurances of ${x} where x takes
the form of a space-separated list of decimal values is replaced with
a sequence of octets corresponding to each value. Hex is a bit more
difficult since the sequences could be confused with a variable names, so
if you want values in hex the simplest thing would be to invent a
different
escape convention, e.g. something like $%x%.
After thinking more about this (and reviewing list of options provided
by Philip), I would like to propose a variables-like syntax close to
what you suggested above:
$%<hex>
controlled by a new Sieve capability "string-escape".
This would give existing implementations an ability to provide the
escaping functionality in both quoted and multiline strings, without the
need to implement variables.
Any objections?
If people don't like this option, my next favorite would be to change
the interpretation of \x.
Alexey