Subject: Working Group Last Call: draft-ietf-sieve-editheader-00.txt

From: Cyrus Daboo <[email-masked]>
Date: Mon, 14 Mar 2005 15:02:51 -0500

I would like to draw your attention to the following draft:

<http://www.ietf.org/internet-drafts/draft-ietf-sieve-editheader-00.txt>

A two week working group last call of this document starts today and ends 
on 28th March 2005 at 6 pm EST.

Please review this document and send issues to the list or direct to the 
author(s).

NB If you do review this document, but have no issues or comments, please 
send both co-chairs (or the list) an email to indicate you have looked at 
it. This will allow the chairs to gauge the scope of reviews of this 
document to aid in our determination on whether to send it to the IESG. 
Thanks.

-- 
Cyrus Daboo
SIEVE WG Co-chair

---

From: Matthew Elvey <[email-masked]>
Date: Mon, 14 Mar 2005 16:42:14 -0800

On 3/14/2005 12:02 PM, Cyrus Daboo sent forth electrons to convey:

> A two week working group last call of this document starts today and 
> ends on 28th March 2005 at 6 pm EST.
>
> Please review this document and send issues to the list or direct to 
> the author(s).
>
> NB If you do review this document, but have no issues or comments, 
> please send both co-chairs (or the list) an email to indicate you have 
> looked at it. This will allow the chairs to gauge the scope of reviews 
> of this document to aid in our determination on whether to send it to 
> the IESG. Thanks.
>
Just trivialities.

Pigeon is misspelled.  We really ought to spellcheck, folks!
Nigegl is misspelt too, as is my name (ok, not really, it's not in there)

PS Is ASCII usually written ascii in RFCs?
I guess someone didn't like Juta's proposed simplification of deleteheader.

Apropos the line:
>   Tests and actions such as "exist" or "header" that examine
The test is "exists", not "exist".  "Exists" and "header" are both 
tests, and actions don't examine.
Therefore, I suggest:
>   Tests such as "exists" or "header" that examine

Sorry I didn't find these sooner.

---

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 22 Mar 2005 12:28:40 -0500

> on 28th March 2005 at 6 pm EST.

A few lingering things...

Abstract

   > This document defines two new actions for the "sieve"
   > language that add and delete email header fields.

There were some comments about a standard way to refer to "Sieve"--
is it "sieve" or "Sieve" or "Sieve email filtering language" etc..

2. Conventions used.

   > Conventions for notations are as in [SIEVE] section 1.1, including
   > use of [KEYWORDS] and "Syntax:" label for the definition of action
   > and tagged arguments syntax.

I think labels are plural, so it ought to read "... labels for
definitions of ..."   (deja vu)

3. Action addheader

In the example:

	> /* Don't redirect if we already redirected */
	> if not header :contains "X-Sieve-Filtered"
	> 	["<[email-masked]>", "<[email-masked]>"]

Just the obligatory comment about using "example.tld" even though "tld"
isn't a real top level domain name today.

8. Acknowledgments

If it's there, "Mallett" not "Mallet" .

General

Should there be remarks about the potential damage that can be
caused to the MIME structure of a message (e.g. by removing/adding
MIME header fields)?

I really miss "replaceheader" and I think it's a huge mistake not to
include it.  "replaceheader" was the only way that one could rename a
header in place, which may have been one source of the objections to it,
but which I found to be the root of its value.  Perhaps a compromise
could be to include "replaceheader" as an optional additional capability
name in this document (the way that "fileinto" is included in the base
spec).

Yours,
-mm-

---

From: [email-masked]
Date: Tue, 22 Mar 2005 10:01:00 -0800 (PST)

> ...

> isn't a real top level domain name today.

RIght, we need to use the "standard" set of example domains throughout.

> caused to the MIME structure of a message (e.g. by removing/adding

This is a big problem. I for one have no intention of letting a change done
with these primitives force a MIME reparse of the message. This makes the cost
of a series of addheader/body operations or any
addheader/anything-that-pays-attention-to-MIME-structure WAY too high. My only
alternative would be to drop support for editheader.

I think we need weasel words to the effect that changing the meaning of the
MIME structure with addheader may not produce results that actually affect
subsequent body or other MIME-related tests.

I should point out that I'm OK with letting addheader affect subsequent header
and address tests. Its a pain to implement in a high performance way, but at
least it can be done efficiently.

> name in this document (the way that "fileinto" is included in the base

FWIW, I miss it too.

				Ned

---

From: "Nigel Swinson" <[email-masked]>
Date: Mon, 28 Mar 2005 14:47:30 +0100

> Please review this document and send issues to the list or direct to the 

Is it worth making it explicit that if deleteheader can't find any matching headers then this isn't an error?

I'm sad that we have to say this:

   Actions that create messages in storage or in transport to
   MTAs MUST store and send messages with the current set of
   header fields.

Certainly it'll break my implementation, as I package up all redirects and fileintos and do them (or cancel them) all in a batch at the end.  I think the above paragraph means that if I allow editheader (which I do) then I'll have to change this or more likely not obey the standard until someone complains.  The feature it gains me seems to be pretty marginal, yet costly to add, so I suspect my implementation will never change.

I think we are saying that editheader does not cancel the implict keep (certainly this makes sense), but I don't think we've been very clear about it.  I liked the clarity of what was said in the vacation draft: "Vacation does not affect Sieve's implicit keep action."

Nigel

---

From: [email-masked]
Date: Tue, 29 Mar 2005 10:01:17 -0800 (PST)

> headers then this isn't an error?

I think it would be.

>    MTAs MUST store and send messages with the current set of

I'm not. This is a very useful feature, one I depend on myself for a couple of
things. It also strikes me as the obvious way for things to work.

> Certainly it'll break my implementation, as I package up all redirects and
> fileintos and do them (or cancel them) all in a batch at the end.

My implementation works the same way, but even so I had no problem implementing
this aspect of editheader. For me the harder part was making the edits visible
to subsequent tests like header, address, exists, etc. I basically maintain a
change list, which can be forked and attached to fileintos, redirects, etc.
This keeps me from having to duplicate the entire header, but it complicates
the tests a bit, especially when an existing header has been removed. (I did
get it working, but the code is kinda nasty - one of those wierd loops that
starts in the middle and has several points of egress.)

A much bigger worry IMO is how this interacts with body and mime. A change
to one of the primary MIME headers can completely change the meaning
of the content, which in turn will force me to have to rescan the message.
A series of operations like this:

    if body :contains "..." ...
    deleteheader "content-transfer-encoding";
    addheader "content-transfer-encoding" "quoted-printable"
    if body :contains "..." ...
    deleteheader "content-transfer-encoding";
    addheader "content-transfer-encoding" "base64"
    if body :contains "..." ...

can force an arbitrary number of rescans. And that's simply not acceptable in a
high performance implementation. Therefore the rule needs to be that both body
and mime may not be affected by the use of editheader operations.

> I think the above paragraph means that if I allow editheader (which I do) then
> I'll have to change this or more likely not obey the standard until someone
> complains.  The feature it gains me seems to be pretty marginal, yet costly to
> add, so I suspect my implementation will never change.

Who knows? Depending on your user base you may be able to get away with this.
I already have uses for per-message-copy header editing, so I don't think
I'd be able to get away with it.

> I think we are saying that editheader does not cancel the implict keep
> (certainly this makes sense), but I don't think we've been very clear about it. 
> I liked the clarity of what was said in the vacation draft: "Vacation does not
> affect Sieve's implicit keep action."

Agreed. This needs to be made explicit in the draft.

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 30 Mar 2005 13:01:59 +0100

>subsequent body or other MIME-related tests.
Good idea.

>least it can be done efficiently.
Sounds good.

>>name in this document (the way that "fileinto" is included in the base
Once addheader and deleteheader are implemented, the cost of 
implementing replaceheader is low. So I would suggest to add 
replaceheader to the document.