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

From: Michael Haardt <[email-masked]>
Date: Thu, 07 Apr 2005 13:10:16 +0200

Hello,

section 3.2 says:

   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 generated message content and the
   recipient.

I agree that's the most sensible algorithm, but it contradicts:

   Vacation responses are not just per address, but are per address per
   set of vacation command arguments.

The arguments :addresses and :days do not influence the message
content.  For that reason, I suggest:

   Vacation responses are not just per address, but are per address per
   generated message.

Michael

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 07 Apr 2005 16:52:45 +0200

>    Vacation responses are not just per address, but are per address per

as has been mentioned, this does not work too well when interacting with
the "variables" extension.  the generated message will often contain the
subject of the original message etc., and therefore be unique.  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.
-- 
Kjetil T.

---

From: [email-masked]
Date: Thu, 07 Apr 2005 08:41:41 -0700 (PDT)

> verbatim unexpanded reason argument.

I agree, however, don't we also want to require that the calculation to include
the :subject argument?

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?

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 7 Apr 2005 18:46:05 +0200

[email-masked] writes:
> 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?

Sound good, but since everyone else is being pedantic I get to go too. 
Does the unexpanded subject strip Re:, or will I get another vacation 
message if I reply to the first vacation message?

Arnt

---

From: Michael Haardt <[email-masked]>
Date: Thu, 7 Apr 2005 18:34:23 +0200

> I agree, however, don't we also want to require that the calculation to include

That's for sure.

> and say that any hash SHOULD cover the unexpanded :subject and reason

I would appreciate that.  Sieve has gotten the critical mass that more
and more systems will offer it soon, and by referecing variables, we
could avoid a repetition of this discussion next year.

Btw: The unexpected may happen and suddenly everybody is happy with the
vacation extension draft. ;-)  I am currently working on the Exim code
and asked, because it was the last open issue for me.

Michael

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 07 Apr 2005 18:53:01 +0200

On Thu, 2005-04-07 at 08:41 -0700, [email-masked] wrote:
> > I suggest

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.  that means only :days and :addresses are
ignored.  :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.)

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.

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.

> and say that any hash SHOULD cover the unexpanded :subject and reason

sounds good to me.
-- 
Kjetil T.

---

From: [email-masked]
Date: Thu, 07 Apr 2005 09:58:18 -0700 (PDT)

> message if I reply to the first vacation message?

I'm full of drugs right now to treat a case of bacterial gastroenteritis so I
may be even more clueless than usual, but this makes no sense to me at all. I'm
talking about the argument to the :subject parameter before any sort of
variable expansion has been done. This means the subject of the message being
responded to is not part of the calculation, and this in turn means the value 
is going to be the same regardless of whether vacation is responding to some
random message or to a response to a vacation message.

Am I missing something here?

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 7 Apr 2005 22:18:48 +0200

> Am I missing something here?

No. I was. Subject != :subject. Sorry.

Arnt

---

From: [email-masked]
Date: Thu, 07 Apr 2005 18:47:14 -0700 (PDT)

> the sent message.

Agreed.

> that means only :days and :addresses are
> ignored.

Agreed.

> :mime is unclear, but you shouldn't have two invocations with

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.

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

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

> 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 [email-masked] sends mail to
   [email-masked] twice, once with the subject "Cyrus bug"
   and once with the subject "come over for dinner", and
   [email-masked] has the script shown below,
   [email-masked] 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

---

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 12 Apr 2005 15:10:08 -0400

>    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

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 13 Apr 2005 13:07:42 +0200

> 	vacation profile, which might be thought of as a representation
[...]

I war trying to do a rewrite myself, but couldn't get it to flow well.
this sounds good to me.

> 	to have the same profile.

you are introducing the term "profile" here, but the keyword is :handle.
I think this mismatch is unfortunate and unnecessary.  :profile is a
better name for the tag.

>           The second way is via a synthesis of
> 	(etc).

okay, so you went back to using all arguments in the hash? or is the
"etc." a reference to some other text.

I'd prefer the text was something like

        The second way is via a synthesis of the other vacation
        arguments which modify the response message, such as ":subject"
        or the reason text.

"such as" is non-commital enough that we can leave the more stringent
explanation for a later paragraph.

incidentally, I don't think it's correct to include :days in the hash.
if you shorten the interval, there is no need to reset the database.
-- 
Kjetil T.

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 13 Apr 2005 22:52:18 -0400

> I think this mismatch is unfortunate and unnecessary.  :profile is a

Either word is fine by me, you are right about the error in using both.

> "etc." a reference to some other text.

Mainly it means that I lost track of what the final concensus was
in this thread.  I just threw in some of them to illustrate a kind
of wording, not to *be* the wording.

> explanation for a later paragraph.

Seems reasonable.

mm

---

From: [email-masked]
Date: Wed, 13 Apr 2005 21:11:31 -0700 (PDT)

> I think this mismatch is unfortunate and unnecessary.  :profile is a

My dictionary disagrees. A profile is a view of something. A handle, OTOH, is a
way to refer to something. The word "profile" is IMO entirely inappropriate as
either a keyword or as a description of what's going on here.

> if you shorten the interval, there is no need to reset the database.

Right, :days clearly does not belong.

In any case, while the addition of some clarifying text is fine, I really don't
like the terminology changes that were made here. I'll see if I can come up
with an alternative that incorporates the descriptive text without changing the
terminology.

				Ned