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

Re: I-D ACTION:draft-ietf-sieve-vacation-01.txt

2005-04-12 12:10:13

On Thu, Apr 07, 2005 at 06:47:14PM -0700, 
ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
OK, so here's the text I currently have:

   Vacation responses are not just per address, but are per address per
   set of :subject, :from, :mime, and reason vacation command arguments.
   For instance, If coyote(_at_)desert(_dot_)example(_dot_)org sends mail to
   roadrunner(_at_)acme(_dot_)example(_dot_)com twice, once with the subject 
"Cyrus bug"
   and once with the subject "come over for dinner", and
   roadrunner(_at_)acme(_dot_)example(_dot_)com has the script shown below,
   coyote(_at_)desert(_dot_)example(_dot_)org would receive two responses, 
once with the
   first message, once with the second.

...

   The "per set of" list of arguments described above is intended to
   ensure that a respondee gets all of the various possible responses,
   not merely the first one.  So, if the :subject or :mime parameters
   would result in a different message, a different message MUST be sent
   by the implementation.

   There is one important exception to this rule, however.  If the sieve
   variables extension [I-D.ietf-sieve-variables] is used, the arguments
   MUST NOT have undergone variable expansion prior to their use in
   response tracking.  This is so that examples like the following
   script will only generate a single response to each incomining
   message with a different subject line.

   require ["vacation", "variables"];
   if header :matches "subject" "*" {
       vacation :subject "Automatic response to: ${1}"
                "I'm away -- send mail to foo in my absence";
   }

...

   Note that one way to implement the necessary mechanism here is to
   store a hash of either the current handle and the recipient or, if no
   handle is provided, a hash of the vacation action parameters
   specifying the message content and the recipient.  If a script is
   changed, implementations MAY reset the records of who has been
   responded to and when they have been responded to.

I'm happy with the vacation statement syntax, and the description is
reasonable, but I also fear that it describes the implementation more
than the intent.  Here's some alternate stub wording (not really fleshed
out) that might illustrate an alternate approach:

        Vacation responses are not just per-address, but are per
        vacation profile, which might be thought of as a representation
        of a vacation message's overall intent.  A script writer might,
        for example, have a general vacation profile that will send a
        return notice only once in any two-week period.  However, even
        if a sender has received this general notice, it may be
        important to return a notice when a message about something
        timely or something specific has been detected.

        A vacation profile is created in one of two ways.  The first way
        is via an explicit handle, which names the profile.  All
        vacation statements that use the same handle will be considered
        to have the same profile.  The second way is via a synthesis of
        the other vacation arguments ":days", ":subject", and ":from"
        (etc).  All vacation statements that do not contain an explicit
        handle and which use an identical combination of these arguments
        are considered to have the same profile.  Note that if the
        "variables" SIEVE extension is being utilized, the sameness test
        is done before any variables expansion.

I'm not suggesting this text, specifically, but suggesting that the
concept of profiles, and why one might want them, be introduced before
the discussion of their implementation and syntax.

mm