[Top] [All Lists]

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

2005-03-30 08:29:18

ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:

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.
Good idea.

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.
Sounds good.

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
FWIW, I miss it too.
Once addheader and deleteheader are implemented, the cost of implementing replaceheader is low. So I would suggest to add replaceheader to the document.