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

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 5 Dec 2006 16:30:48 -0500

On Wed, Nov 22, 2006 at 02:37:40PM -0500, Cyrus Daboo wrote:
> 
> Hi folks,
> In light of changes to the base spec since the previous working group last 
> call on the editheader extension, we would like to re-issue the last call 
> on draft-ietf-sieve-editheader-07.txt. Please note that we are "scoping" 
> this last call to only issues related to base spec changes. No new issues 
> will be considered.

Some comments, although it looks like none of them meet the criteria in
those last two sentences.  Take or drop on the floor as you will ..

> 4. Action deleteheader
> 
>    The field-name is mandatory and always matched as a case-insensitive
>    US-ASCII string.  If the field-name is not a valid 7-bit header
>    field name as described by the [IMAIL] "field-name" nonterminal
>    syntax element, the implementation MUST flag an error.  The

There's a dangling "The" there.

> 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.  One might want the unaltered headers in order to
debug the failing script, but that's a different thing.

Yours,
mm

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 07 Dec 2006 15:30:27 +0000

Mark E. Mallett wrote:

>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

---

From: Ned Freed <[email-masked]>
Date: Fri, 08 Dec 2006 19:31:06 -0800 (PST)

> partially applied header changes) seems to be the best.

I agree with this analysis. Our implementation could have handled the
attachment of header information in the event of an error either way without
too much trouble, but I think what the draft describes is the correct approach.

				Ned