ietf-mta-filters
[Top] [All Lists]

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

2006-12-05 14:41:18

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

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