ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
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.
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
spec).
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.