[Top] [All Lists]

Re: variables draft (draft-homme-sieve-variables-00.txt)

2003-04-08 10:18:54

  (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

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?

I really don't see the point of storing the static parts of the pattern. It
will also confuse people familiar with capture systems for patterns, since
AFAIK none of them work this way.

So yes, I think this is too complex for too little gain.

isn't it likely
that those who implement variables will also implement regex?

Well, I for one intend to provide both, but regex will be disabled by default
and given some of the security risks I expect it will have I doubt if many
users of ours will be willing to enable it.

      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.

Well, it isn't clear to me that we want to encourage storing massive texts in
variables. I think the preferred approach is to use variables to store smallish
substitutions into larger texts.

Philosophy aside, I'm more concerned about limits on the all-digit variables
since they come into being automatically than I am on the limits on explicitly
specified variables. I could tolerate having a large limit on variables in
general as long as a smaller limit could apply to all-digit variables. Although
come to think of it, the base specification allows considerable leeway on
implementation limits, so I guess I could consider limits on :matches as an
implementation limit allowed by the base specification.

  (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.

This is what I meant.

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?

No, nothing like that. I suppose it is possible for two extensions to
be incompatible in some way, but that's a bridge we can cross if we ever
come to it.

  (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.

WFM, although there have been some other objections here...

  (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).

A copy was posted to the imapext list on 26-Feb. Hopefully Chris will
be able to post an updated version to the I-D directory soon.

    SET :upper :comparator "i;ascii-casemap" name "${1}"

I like this a lot better than the present modifier syntax. You do need to
specify the combining rules for :upper/:lower/:upperfirst/:lowerfirst. I think
the rule should be that :upper and :lower are incompatiblei with each and so
are :upperfirst and :lowerfirst. And if :Xfirst is specified along with :Y, :Y
is done prior to :Xfirst.

"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.

They would represent an identity case mapping I guess. I believe Chris plans to
deal with this issue in his document.

  (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.

The problem is that the Olson database is constantly being changed and updated,
which means any snapshot you take has a good chance of being at odds with
reality in fairly short order. (A political rather than technical base tends to
do this... I understand that there are 1-2 updates every month or so.) So
absent the wherewithall to basically have IANA act as a handler for the Olson
effort or something similar, I see serious problems here.

      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

You can simply refer to it. No need to repeat it.

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";

Interesting. I could go with this.

  (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.

Then by all means make the zone one that's local to the user rather than to the
server. I really don't think having a default of UTC is the right answer here.

  (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

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.

Works for me.

  (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.

Yes, but harder to deal with in actions. I don't feel comfortable trying to
predict whether actions are going to be more common than 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,


       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

  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";

Date would test date values in headers. There are all sorts of those, and
there is considerable value in being able to test them.


<Prev in Thread] Current Thread [Next in Thread>