On Mon, Mar 14, 2005 at 03:02:51PM -0500, Cyrus Daboo wrote:
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.
A few lingering things...
...
In the example:
> /* Don't redirect if we already redirected */
> if not header :contains "X-Sieve-Filtered"
> ["<kim(_at_)job(_dot_)tld>", "<kim(_at_)home(_dot_)tld>"]
Just the obligatory comment about using "example.tld" even though "tld"
isn't a real top level domain name today.
RIght, we need to use the "standard" set of example domains throughout.
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)?
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.
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).
FWIW, I miss it too.
Ned