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