I have just finished implementing this draft. Nice work -- It was considerably
easier to do than I expected.
Of course I now have a number of comments:
(1) The ${0}, ${1} all-digit variables should be set and modified by the
glob-style :matches mechanism in addition to :regex. It really should
not be necessary to implement regex in order to get the ability to
set variables based on message inputs. For example:
require ["variables", "envelope", "subaddress"];
if allof(envelope :all :is "from" "a(_at_)b",
envelope :detail :matches "to" "*")
redirect "d+${1}(_at_)e"
Of course glob style patterns don't have the ability to specify
which wildcard characters capture and which do not, but I really don't
this this will be a problem in practice.
The presence of "variables" in the require list should be sufficient
to enable setting of the all-digit variables by :matches.
(2) Implementations should be able to impose limits on the total number of
variables as well as the size of any particular variable. With such
limits it is easy to write scripts that consume an unreasonable amount
of space:
require "variables";
set a "aaaaaaaaaa";
set a "${a}${a}${a}${a}${a}${a}${a}${a}${a}${a}";
set a "${a}${a}${a}${a}${a}${a}${a}${a}${a}${a}";
set a "${a}${a}${a}${a}${a}${a}${a}${a}${a}${a}";
set a "${a}${a}${a}${a}${a}${a}${a}${a}${a}${a}";
...
That's already 100000 characters, with no end in sight.
I suggest minimum maximums of 64 variables that can each hold 998
characters.
(3) The draft needs to make it clear that ${} constructs are not interpreted
in a special way inside of strings unless the "variables" extension is
listed in a require clause.
(4) There's a comment to the effect that fileinto needs to be extended to
create folders if they don't already exist. As far as I can tell the
specification of fileinto in RFC 3028 is silent on the folder creation
issue. Our implementation certainly allows folder creation by fileinto;
I suspect others do as well. But regardless, I think this is a matter
that needs to be clarified in the base sieve specification; I don't think
it calls for a separate extension.
(5) Other than we decide on something and stick with it, I have no preference
for modifier ordering.
(6) The selection of specific lowercasing or uppercasing rules for lower: and
upper: needs to be done by specifying a comparator. Comparators have
implement case conversion rules. Chris Newman has a new draft that
cleans up the situation surrounding the comparator registry but it isn't
out as an I-D yet.
(7) The setdate operator accept a "time zone" argument. And this is exactly
what it should take. However, what's currently specified is a time offset,
not a time zone -- the former is something like -0800 while the latter is
something like "US/Pacific". Unfortunately the IETF does not presently have
a time zone rules registry. This has been a problem for some time and
I don't see it changing any time soon. I suggest that the correct
approach to take is the one RFC 2445 uses. I would also like to allow
a time offset as an argument to setdate, but zone support is what's needed.
(8) The default zone for setdate should probably be the zone local to the
server. I think this makes a lot more sense than GMT.
(9) The specification of setdate needs to state that every setdate in a
given script operates on a single, consistent date/time value that does not
change throughout the execution of the script. If you don't do this you
can get some unpleasant boundary cases. Note that it is entirely
reasonable to use setdate multiple times in a single script, either
because of automated script construction or else because someone
wants the current date in different time offsets.
(10) I had been planning to write up a specification for currentdate and date
tests. The former would allow testing of current date information while
the latter would be similar to the address test except it would operate on
fields containing date information.
Setdate and currentdate provide equivalent functionality: Setdate combined
with the string test give you the ability to test current date information
while currentdate combined with :matches and the set action give you the
ability to get date information into the variable of your choice. Of course
each one is better syntax-wise at doing what it is directly designed to
do:
setdate "+0200" if currentdate :year :matches "*"
fileinto "${year}-${month}" set year "${1}"
if currentdate :month :matches "*"
set month "${1}"
fileinto "${year}-${month}"
setdate "+0200" if currentdate :year :is "2003"
if string :is "${year}" "2003" ...
...
I'm inclined to go with setdate at this point, mostly because the
setdate syntax seems simpler to use overall. My one remaining concern
is that setdate doesn't match up well with the obvious syntax the
date test needs to have. So I'd appreciate feedback from others on this
point.
That's enough for now. As I said at the beginning, I think this is very good
document and I hope we can advance it sooner rather than later.
Ned