[ned(_dot_)freed(_at_)mrochek(_dot_)com]:
I have just finished implementing this draft. Nice work -- It was
considerably easier to do than I expected.
thank you.
(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.
your example shows that it is possible to do useful things with it, at
least.
it is possible to add, though. one method is to split the match
string on the meta characters. consider the string "*(_at_)*(_dot_)com" -- we
split this in four, "*", "@", "*" and ".com". ${2} and ${4} will
always be "@" and ".com" (if there's a match), but ${1} and ${3} will
contain the matching characters.
does this sound too complicated for too little gain? isn't it likely
that those who implement variables will also implement regex?
The presence of "variables" in the require list should be
sufficient to enable setting of the all-digit variables by
:matches.
I agree.
(2) Implementations should be able to impose limits on the total
number of variables as well as the size of any particular
variable.
good catch!
I suggest minimum maximums of 64 variables that can each hold
998 characters.
while there is a tradition for 998 characters as a maximum line
length, I think it is very low for this application. remember that
some people may want to put longish vacation messages inside
variables. I suggest 30000 characters (not octets) and an even
hundred variables as minimum.
(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.
not sure what you want here. either a clarification in the
introduction like:
This is an extension to the Sieve language defined by [SIEVE]. It
adds support for storing and referencing data in string variables.
+ The mechanisms detailed in this document will only apply to Sieve
+ scripts which include a require clause for the "variables"
+ extension.
or, do you want to outlaw making a different extension which is
mutually incompatible with "variables"? is that even possible to do
without updating the base specification?
(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.
okay. clearly independent of "variables", anyhow.
(5) Other than we decide on something and stick with it, I have no
preference for modifier ordering.
let's stick to prefixing (function call like), then.
(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.
interesting. do you know where I can get a copy? I wonder how to
cram this into the modifier syntax, though. perhaps the current
approach is completely wrong. rather than stick modifiers inside the
strings, we could make them modify the SET action. it seems a better
fit to fit other elements of Sieve (both syntax and semantics).
SET :upper :comparator "i;ascii-casemap" name "${1}"
"i;ascii-casemap" would be the default comparator for SET. I'm not
sure what the meaning of using "i;ascii-numeric" or "i;octet" with SET
should be. they may make more sense if other modifiers are added in
the future.
sorry, I should have thought of that approach earlier.
(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.
what would it take to get it changed? it seems to me they could just
take (a subset of) the Olson database and decree it as official.
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.
interesting, thanks for the reference. do you mean to include the
whole vocabulary to define a time zone? that seems very complex to
me.
one pragmatic approach is to allow "well-known" time zones with a
fallback offset value supplied by the user:
setdate "US-Eastern" "-0500"
to allow the user to discover that the time zone was unknown, a
variable called "timezone" would be set to the value actually used.
there should be a note that if IETF establishes a registry for time
zones, the values in it SHOULD be used. if no fallback value is
specified, use the server's default.
actually, with ${timezone} available, the fallback can be implemented
by the user. we simply need to mandate that the time offset syntax is
supported as a valid "time zone".
setdate "US-Eastern";
if not string "${timezone}" "US-Eastern" {
setdate "-0500";
}
(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.
the objection to that was that a Sieve script should behave the same
way even if it was moved to a server in a different time zone. e.g.,
imagine a local ISP in the UK being swallowed up by a pan-European ISP
which centralises all email servers in Brussels. that must lead to
breakage for customers.
(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.
agreed. how about this?
These variables SHOULD reference the time when execution of the
Sieve script reaches the statement.
+ The result of all calls to setdate MUST refer to the same point in
+ time.
(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 "+0200" if currentdate :year :is "2003"
if string :is "${year}" "2003" ...
...
the currentdate syntax is obviously easier to read in tests.
I'm inclined to go with setdate at this point, mostly because
the setdate syntax seems simpler to use overall.
it allows general use without an IF and SET for every value needed,
yeah.
My one remaining concern is that setdate doesn't match up
well with the obvious syntax the date test needs to have.
what date tests are needed? Sieve is quite expressive already. an
example:
require [ "variables", "vacation", "relational" ];
setdate "+0200";
if string :value "le" "${year}-${month}-${day}" "2003-09-18" {
vacation "I'm on my holidays, I'll be back on Sept. 19th";
}
--
Kjetil T.