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 mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve