On Thu, 2005-04-07 at 08:41 -0700, ned(_dot_)freed(_at_)mrochek(_dot_)com
wrote:
I suggest
Vacation responses are not just per address, but are per address and
reason argument.
I think that makes it clearer that the intent is to consider the
verbatim unexpanded reason argument.
I agree, however, don't we also want to require that the calculation to
include
the :subject argument?
okay, so here are all the possible arguments:
Syntax: vacation [":days" number] [":subject" string] [":from"
string]
[":addresses" string-list] [":mime"] [":handle" string]
<reason: string>
we could the split depending on whether the option has an influence on
the sent message.
Agreed.
that means only :days and :addresses are
ignored.
Agreed.
:mime is unclear, but you shouldn't have two invocations with
the same reason, one with :mime and the other without. (actually, you
_can_ do that if the MIME bits are put in a variable, so let's include
the existence of :mime in the hash, too.)
True, but since it significantly influences the message being generated
I think it best to include it. I probably can be convinced otherwise
if folks feel strongly about excluding it.
that said, I'm not particularily concerned about the specification
causing too few messages to be sent. after all, the case we're
discussing is how many reminder messages should be sent. the sender
will always receive at least one vacation message.
Yes, but if situations change faster than the retention time not
sending a response is tantamount to not sending a vacation message.
I'm leaning towards keeping it simple, particularily since the user
explicitly can get the behaviour he wants using :handle. in other
words, stick to just the reason.
IMO :subject has to be in there. A very common thing I see is to
set the subject to something like "I'm away until blah" and have
a reason saying "if you need help sooner please do this and that
and so on and so forth". That reason text only changes when the person's
responsibilities change, they simply edit the subject text each time
they're out of the office.
Keep in mind that vacation is something of a misnomer. People use this
mechanism for all manner of out of office replies with periods much shorter
than the typical :days value. (And yes, I've thought about changing the name of
the action, but rejected it because calling this a vacation autoresponder is
deeply engrained in email culture.)
The other argument is :from. This definitely changes the message, so I've
included it for now, but like :mime I could be convinced to drop it.
I believe there was a time when we didn't want to refer to variables in the
vacation draft bevcause it was assumed variables would take much longer to
complete. That's no longer true - variables is in last call while we're
still
fine tuning vacation. So how about simply referring to the variables
document
and say that any hash SHOULD cover the unexpanded :subject and reason
arguments?
sounds good to me.
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.
Does this do the job?
Ned