ietf-mta-filters
[Top] [All Lists]

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

2003-04-08 16:00:11

[Ned Freed]:

  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.

I added this section to the draft:

6.  Implementation Limits

An implementation of this draft MUST support at least 128 distinct
variables.  The supported length of variable names MUST be at least 32
characters.  The supported size of a variable's content MUST be at
least 4095 octets.  Attempts to set the variable to a value larger
than the implementation supports MUST be treated as an error.

Numeric variables ${1} through ${9} MUST be supported.  Referencing
higher indices than is supported is a syntax error which MUST be
discovered at compile-time.  If the string matching a wildcard or a
regex group operator exceeds the maximum variable size, the
implementation SHOULD truncate it and MUST NOT treat it as an error.
=== ends ===

I hope this addresses your concerns.

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

added, thanks.

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

thanks, it's at http://article.gmane.org/gmane.ietf.imapext/1436

  >     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 incompatible with each and so are :upperfirst and
  :lowerfirst.  And if :Xfirst is specified along with :Y, :Y is
  done prior to :Xfirst.

so tags in Sieve MUST be commutative?

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

ok.  my current wording:

  Note: There is currently no registry for time zones.  If IETF
  establishes one, its names SHOULD be used.  In the absence of such a
  registry, [TZ] is the most widespread collection of time zone
  definitions and its use as a reference is RECOMMENDED.

(where [TZ] refers to Olson et al. of course)

  
  > >       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.
  
  You can simply refer to it. No need to repeat it.

oh, I was worried about the implementation :-).  also, now the
responsibility for keeping the time zone definition up-to-date rests
on the Sieve client, not the server.  also, the time zone definition
could be implemented by the client using a bunch of IFs and a couple
of calls on SETDATE...

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

great :-)

  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.

I'm with you, and these changes in SETDATE makes it easier to bear.

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

ah...  yes, this is useful functionality, especially for filtering
email archives.  perhaps we could generalise SETDATE?

   SETDATE :now "+0200";        # old behaviour
   SETDATE :header "Date";
   SETDATE :header "Date" "+0000";

the default time zone for :header should be the one specified in the
header.

(what to do if there is no such header, or it can't be parsed?)
-- 
Kjetil T.

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