Subject: AD Evaluation Comments: draft-ietf-sieve-vacation-04

From: "Scott Hollenbeck" <[email-masked]>
Date: Thu, 20 Oct 2005 13:20:07 -0400

Some questions and comments, also noted in the I-D Tracker.  Please clue me
in as appropriate:

Minor IDNit errors are noted in the tracker.  The shepherd write-up said
that IDNits ran cleanly.  Hmm...

General comment: both "Sieve" and "sieve" are used in the document.  One
form or the other should be used consistently.

First page:
The "??" characters used for Tim's organization need to be replaced.  To be
honest I'm not sure if anything should be used at all if there is no know
organization.

Section 4.1:
I'm curious about the "Sites MAY also define a maximum days value, which
MUST be greater than 7, and SHOULD be greater than 30" text.  Why use a MUST
for what appears to be an operational matter?  What is the impact on
interoperability if a lesser value is used?

Section 4.2:  "Implementations are free to limit the number of remembered
responses, provided the limit is no less than 1000."
Why 1000, and is this a normative requirement or not?

Section 4.7: "A script will fail if it attempts to execute two or more
vacation actions."
Should "will" be either SHOULD or MUST?  "will" describes an implementation
behavior.

-Scott-

---

From: Ned Freed <[email-masked]>
Date: Thu, 20 Oct 2005 10:44:36 -0700 (PDT)

> that IDNits ran cleanly.  Hmm...

The two nits appear to be additional spaces between words. I've removed them.
(For the record, I think this is a stupid and unnecessary check for idnits to
make, especially since the vagarities of line breaking can create situations
where extra space lurks indefinitely in a document.)

> form or the other should be used consistently.

It's a proper name for a language so "Sieve" would appear to be the better
choice (except in file names, of course). Fixed.

> honest I'm not sure if anything should be used at all if there is no know

xml2rfc (incorrectly IMO - since we all participate as individuals, why can't I
be an entirely unaffiliated draft author?) insists on having an organization
field. I fired off a note to Tim asking him what he wants to have there. Best
I can do.

> interoperability if a lesser value is used?

Simple: In order to write portable scripts there needs to be some guarantee as
to how big a :days value you can specify. This requirement means a script that
specifies a value of 7 or less is guaranteed to run on any compliant Sieve
system that supports vacation. Without this requirement you don't have such a
guarantee.

> Why 1000, and is this a normative requirement or not?

1000 seemed like a reasonable value. It is no more justified (or justifiable)
than, say, the 1000 character line length limit in SMTP.

I'll make the language normative.

> Should "will" be either SHOULD or MUST?  "will" describes an implementation

I'll make it a MUST.

				Ned

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 20 Oct 2005 15:46:19 -0400

Hi Ned,

--On October 20, 2005 10:44:36 AM -0700 Ned Freed <[email-masked]> 
wrote:

>> First page:
>> The "??" characters used for Tim's organization need to be replaced.  To
>> be honest I'm not sure if anything should be used at all if there is no
>> know organization.
>
> xml2rfc (incorrectly IMO - since we all participate as individuals, why
> can't I be an entirely unaffiliated draft author?) insists on having an
> organization field. I fired off a note to Tim asking him what he wants to
> have there. Best I can do.

I simply leave <organization/> as an empty element and that seems to do the 
right thing.

-- 
Cyrus Daboo

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Thu, 20 Oct 2005 15:50:11 -0400

Thoughts below.

> -----Original Message-----
> From: Ned Freed [mailto:[email-masked]] 
> Sent: Thursday, October 20, 2005 1:45 PM
> To: Scott Hollenbeck
> Cc: [email-masked]
> Subject: Re: AD Evaluation Comments: draft-ietf-sieve-vacation-04
> 

Agreed.  As I said in a private note to Cyrus, his write-up said that the
nits checker ran cleanly.  I wasn't sure if that meant that he didn't see
this little warnings, or if they didn't pop up.  No big deal.

> field. I fired off a note to Tim asking him what he wants to 

Would quoted blanks work?  I've never tried myself.

> > Should "will" be either SHOULD or MUST?  "will" describes 

OK, I'm satisfied.  There's nothing serious enough to warrant revision
before the last call.  Queue them up for processing along with anything else
that comes up.

Thanks for the quick response,
-Scott-

---

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 20 Oct 2005 15:58:35 -0400

> Should "will" be either SHOULD or MUST?  "will" describes an implementation

I also had a comment on 4.7 that I sent off-list.  Essentially:

    I did wonder about that wording; seems to me that the the script as
    a whole probably shouldn't fail, but the non-first vacation
    action(s) should give an error.  i.e. duplication vacation actions
    should fail, not abort the entire script.  (Not to mention that if
    the script were to fail on the second "vacation" then there would be
    no need to say "or more".)

Another nit was:

> 5.8  In-Reply-To and References
   >
   > Section 3.6.2 of [RFC2822] provides a complete description of how
   > References fields should be generated.

   Pretty sure that's supposed to be section 3.6.4

Plus some minor comment about the spelling of my name :-)

-mm-

---

From: Michael Haardt <[email-masked]>
Date: Fri, 21 Oct 2005 01:22:08 +0200

>     no need to say "or more".)

The base spec says:

   When an error occurs in a Sieve script, all processing stops.

So either you ignore vacation actions starting at the second one, or
you generate an error.  If an error is generated, all processing stops.
If so, indeed there can't be a third.

I'd say, let's include an example showing two vacation actions and
a fileinto afterwards, stating the fileinto can not happen (assuming
the second vacation action does generate an error), but:

Does the base spec allow action execution reordering?

That's not as crazy as it sounds.  Of course actions with side effects
must not be reordered, that goes without saying.  And how about actions
without side effects?

fileinto "a";
fileinto "b";

If a message is filed to "b", will there be one in "a", or could
both actions be processed simultaneous after the script ran, "a"
fails with a runtime error and "b" suceeds?

I expect that

redirect "a@nosuchdomain";
redirect "[email-masked]";

may well send a message to "[email-masked]", despite the first
causing a run-time error, because the action sets up the delivery of
the message, but does not deliver it on its own.  But strictly
speaking, this _is_ action reordering.  We need to say something about
this topic.

In case the second vacation causes an error: How would an example
for that look like?

While thinking about it: The base spec does not define if anyof and
allof perform shortcut/lazy evaluation.  After all the years, all we can
probably do is saying that depends on the implementation.  It should be
mentioned, because it may cause the same script to behave different on
different implementations.

Oh well.

>    Pretty sure that's supposed to be section 3.6.4

I agree.

Michael

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Fri, 21 Oct 2005 02:45:34 +0200

> different implementations.

well, in 3028 tests cannot have side effects, so it isn't possible to
tell.  this restriction has been lifted to allow for the match variables
in variables, and that draft says:

   The interpreter MUST short-circuit tests, ie. not perform more tests
   than necessary to find the result.  Evaluation order MUST be left to
   right.  If a test has two or more list arguments, the implementation
   is free to choose which to iterate over first.

however, the future may bring other extensions which introduce tests
with side effects, so I guess it could be nice to have the above
clarification in the base spec, although conformance is not observable
with the base spec alone.

-- 
Kjetil T.

---

From: Aaron Stone <[email-masked]>
Date: Thu, 20 Oct 2005 16:58:12 -0700

> speaking, this _is_ action reordering.  We need to say something about

I don't believe this is action reordering. What you're presupposing is
that the message is redirected in an asynchronous manner (as is
reasonable in any modern mail system), but then you're broadly
redefining the out-of-order _results_ as action reordering.

Aaron

---

From: Michael Haardt <[email-masked]>
Date: Fri, 21 Oct 2005 10:39:13 +0200

> redefining the out-of-order _results_ as action reordering.

As I said, with mails, this behaviour is expected.  In common programming
languages, statements are executed strictly sequential, including all
side effects and exceptions from that rule are specified in great detail.

Your suggestion to look at results (external side effects) may be the
solution.  I suggest:

  With regard to side effects on the state of the Sieve machine, all
  commands are processed strictly sequential, but side effects outside the
  Sieve machine, such as filed or redirected mails, MAY happen out of order.
  Run time errors on external side effects MAY not have any influence on
  the Sieve machine.

Now all we need may be putting that into words that can be understood. ;-)

The MAY tries to say that this is yet another place where the same script
may yield different results on different systems.  Improvements are more
than welcome.

Since the second vacation command has the side effect of generating an
error inside the Sieve machine (internal side effect), execution must
stop exactly there.  A fileinto afterwards will never be executed, if
we agree on the above behaviour.

Michael

---

From: Michael Haardt <[email-masked]>
Date: Fri, 21 Oct 2005 12:39:22 +0200

> with the base spec alone.

No, it is.  From section 2.6.10, Errors:

   Implementations MUST perform syntactic, semantic, and run-time checks
   on code that is actually executed.  Implementations MAY perform those
   checks or any part of them on code that is not reached during
   execution.

That means, "anyof" with one semantically valid test, that evaluates to
true, and one semantically invalid test, will evaluate to true, if using
shortcut evaluation and lazy checks, and generate an error with strict
evaluation or strict checks.

You mentioned another point: Evaluation order.  Indeed that is not
specified either, and it can be observed as well.

I would like to see short-cut evaluation and evaluation order from
left to right in the base spec, but I am not sure if we can do that.
It is an incompatible change.  Oops, I said the i-word.

Michael

---

From: Ned Freed <[email-masked]>
Date: Fri, 21 Oct 2005 10:43:22 -0700 (PDT)

> I simply leave <organization/> as an empty element and that seems to do the

OK, I'll try that.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Fri, 21 Oct 2005 10:44:20 -0700 (PDT)

>     no need to say "or more".)

I think this is an absolutely terrible idea. VIolations of the least
astonishment principle abound. Consider:

    vacation whatever1;
    vacation whatever2;
    if test {fileinto blah;}

If the test fails the script appears to work, sending one vacation response
but not the other. But if the test succeeds the script now fails for reasons
having nothing to do with the test. Such a gotcha can remain hidden
indefinitely only to go off when you least expect it - a script landmine.

Plenty of similar examples can be constructed but I think this is sufficient
to demonstrate that far from improving error handling, this makes a mess of it.

>    Pretty sure that's supposed to be section 3.6.4

Fixed.

> Plus some minor comment about the spelling of my name :-)

Sorry about that. Also fixed.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Fri, 21 Oct 2005 10:52:17 -0700 (PDT)

> the second vacation action does generate an error), but:

I see no reason to have such an example.

> Does the base spec allow action execution reordering?

There's no prohibition against it, so the answer would apppear to be "yes". The
base spec does go so far as to say that you can perform actions as you go or
wait until evaluation is complete and then perform them all.

> That's not as crazy as it sounds.

IMO it doesn't sound crazy at all.

> Of course actions with side effects

> fails with a runtime error and "b" suceeds?

Sure, that's possible. Or you could have a situation where "a" is over quota
but "b" is not. And what about transient quota errors? Suppose "a" is over
quota but still within it's "grace period" where messages are queued rather
than bounced. So the message to "a" sits in a queue somewhere but "b" sails
through.

Implementations have to deal with all of these issues and many more. Actual
delivery to the folder may be deferred until long after the script has
executed, making it effectively impossible to convert a delivery failure into a
script failure. And even if it is possible for fileinto, it isn't for
redirect, as you point out below.

> speaking, this _is_ action reordering.  We need to say something about

I disagree. I don't think we have to discuss each and every thing we
don't prohibit.

> different implementations.

It is mentioned to the extent that the spec says short circuit evaluation
is encouraged. I remain to be convinced that more is better here.

				Ned

---

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 21 Oct 2005 15:30:25 -0400

On Fri, Oct 21, 2005 at 10:44:20AM -0700, Ned Freed wrote:
> I think this is an absolutely terrible idea.

Which idea do you think is terrible?  Multiple vacations causing a script
to fail, or simply reporting an error on a multiple vacation?

> VIolations of the least

I do not understand this example at all; perhaps some more words would
help light the bulb.  (or perhaps hitting "send" on this message will do
it :-) ).  If anything, it sounds like you do not want the script to
fail if there are multiple vacation statements.  But I don't understand
how the success or failure of the test causes any more of a debugging
problem with any particular duplicate-vacation handling vs another.

-mm-

---

From: Ned Freed <[email-masked]>
Date: Fri, 21 Oct 2005 13:07:53 -0700 (PDT)

> to fail, or simply reporting an error on a multiple vacation?

The idea that multiple vacation action errors should be silently ignored
until the first non-vacation action is taken.

> fail if there are multiple vacation statements.

No. That's exactly the opposite of what I want.

> But I don't understand

The minute you have failure cases that don't report when encountered and
instead wait for some other condition to arise before becoming an error you've
got a mess on your hands.

				Ned

---

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 21 Oct 2005 16:42:03 -0400

> until the first non-vacation action is taken.

Ah.  But that's a third case.  Why would the first non-vacation action
cause an error?  The context was whether in:

   vacation :handle x "something";   # A
   vacation :handle x "something";   # B

whether executing B causes the script to fail, or whether the script
continues past B (suppressing the execution of the B action, whether
noting an error or not).  A later non-vacation action (in this case,
"fileinto") shouldn't cause an error whether there is one vacation
statement or two.  So the example is still confusing to me.
Particularly the comment about the success of the test mattering, rather
than the multiple vacation actions being executed.

Hmm, going back again... perhaps you were reading my "non-first
vacation" as "non-vacation" ?

There is certainly precedent for suppressing duplicate vacation
actions.  The base spec says (at least the way I read it, and thus the
way I implemented it) that multiple attempts to file into a folder will
be silently suppressed.  See 2.10.3, which says:

   > Implementations SHOULD NOT deliver a message to the same folder more
   > than once, even if a script explicitly asks for a message to be
   > written to a mailbox twice.
   > 
   > The test for equality of two messages is implementation-defined.
   > 
   > If a script asks for a message to be written to a mailbox twice, it
   > MUST NOT be treated as an error.

I don't know the reasoning behind this, but I assumed it is to make it
convenient and harmless for a script writer to express their intent to
write a message into a particular folder when more than one test
succeeds.  ("I twice intend to write into this folder" rather than "I
intend to write into this folder twice").

> > > indefinitely only to go off when you least expect it - a script landmine.

I still don't get that.  Probably it's me.  When you invoke the
principle of least astonishment, I find that that is accomplished by
making the vacation action work in the same way as fileinto, for the
same reason.  And with duplicate vacation causing a failure, you get
that 'landmine' (which I would simply describe as a coding error) even
more with:

   vacation whatever1;
   if test { vacation whatever2; }
   fileinto "blah";

since when the test fails, you get one vacation response and the message
filed into blah; if the test succeeds, you get a vacation response and
you do not get the message filed into blah (rather, the inbox).  This
seems more along the lines of your view of a landmine; how is this
better?

> got a mess on your hands.

I completely agree with that.  What I don't understand is how it applies
to this particular point.  (OTOH, unrelated to vacation, it could apply
in an implementation that defers actions.)

Yours,
-mm-

---

From: Ned Freed <[email-masked]>
Date: Fri, 21 Oct 2005 15:15:32 -0700 (PDT)

> noting an error or not).

It should cause the script to fail.

> A later non-vacation action (in this case,

> vacation" as "non-vacation" ?

Yes.

> actions.

I disagree. AFAIK we have no other situation where repeating an action is
supposed to be an error but repeating an identical action doesn't produce an
error. The obvious case where repeating an action is an error is reject, and
it's an error even if the second reject is identical.

> The base spec says (at least the way I read it, and thus the
> be silently suppressed.

The cases are not really comparable. Multiple fileintos are not an automatic
error. The only time multiple fileintos would produce an error is when they
exceed the implementation's limit on fileintos, and the spec is silent (as it
should be) on whether or not such a limit counts identical fileinto separately
or not.

> same reason.

Perhaps, but this consideration is trumped by the fact that sending multiple
vacation messages is a bad thing thing. Multiple fileintos, OTOH, make total
sense in a lot of cases.

> And with duplicate vacation causing a failure, you get

>    if test { vacation whatever2; }

Some issues can be avoided, others cannot. Deferring errors is something we can
avoid specifying. Unless we're willing to make all actions unconditionally
compatible with all others we cannot possibly get rid of all these cases.
Making something like:

    reject "foo"
    if test { fileinto "bar";}

work regardless of how the test turns out isn't worth eliminating the
restriction that reject isn't compatible with most other actions.

> in an implementation that defers actions.)

See above. I don't know what else I can say.

				Ned

---

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 21 Oct 2005 19:20:42 -0400

> > vacation" as "non-vacation" ?

OK.  That explains the disconnect, and renders a lot of this
mini-thread irrelevant.

If you thought I was suggesting that the first non-vacation action
after multiple vacation actions should cause an error, well, you
were very generous in your responses :-)

> should be) on whether or not such a limit counts identical fileinto separately

I understand that difference, and your perspective on it.  Me, I
find de-duplication of identical vacations (and even rejects) to
offer the most consistency and utility.  But I'll implement whatever
the RFC ends up saying in this regard.

> See above. I don't know what else I can say.

It was explained by the fundamental miscommunication anyway.

Yours,
-mm-

---

From: Ned Freed <[email-masked]>
Date: Sat, 22 Oct 2005 15:08:00 -0700 (PDT)

> were very generous in your responses :-)

OK, got it. I'm really glad to hear this isn't what you were proposing.

				Ned