[Top] [All Lists]

Re: WGLC: draft-ietf-sieve-editheader-07.txt

2006-12-07 08:47:24

Mark E. Mallett wrote:

5. Interaction with Other Sieve Extensions
I guess I didn't notice when the first paragraph here got added in;
looks from the change history that it was in -05.  (If it's too late for
this comment, so be it.)  This part:
  Actions that generate [MDN], [DSN], or similar disposition
  messages MUST do so using the original, unmodified message header.
is the correct thing to do (even though it will give me something
to do to fix the way my code behaves).  But:
  Similarly, if an error terminates processing of the script, the
  original message header MUST be used when doing the implicit
  keep required by [SIEVE] section 2.10.6.
It looks like the reference to 2.10.6 is simply to justify the implicit
keep, and not the behavior of keeping the original message header.
Still, I can't help but think that that behavior is not in the spirit of
2.10.6, which which says (among other things) that implementations may
choose whether to iteratively parse/execute until an error, in which
case "some actions happen, others don't."  This seems to me to be the
opposite of justifying undoing already-executed actions when performing
implicit keep.

Of course, maybe I am reading it that way because I want to, since I
have a hard time understanding why anybody would want this.  If
addheader/deleteheader succeed, it seems to me that a script writer
would expect the kept copy to have the results of the script actions
that had succeeded.

But in ideal world we don't want to have partially executed scripts. The text in 3028bis is describing real world and is much more liberal than I would like it to be.

For debugging of a Sieve script it is much better to know in which state the saved message is. So using the original message (before any partially applied header changes) seems to be the best.

 One might want the unaltered headers in order to
debug the failing script, but that's a different thing.

<Prev in Thread] Current Thread [Next in Thread>