On Wed, Jan 07, 2004 at 06:03:04PM -0500, Mark E. Mallett wrote:
Two very interesting changes in this draft:
"addheader" [":last"] <name: string> <value: string>
By default, the header field is inserted at the beginning of
the existing header. If the optional flag ":last" is
specified, it is appended at the end.
What's the rationale? So far (i.e., without hearing more), I liked it
better the way it was: the default being to add the header at the end,
not the beginning. I would not mind seeing a ":first" to alter that
behaviour though.
It's much easier to insert a header field at the beginning of
a header (one simply sends that header field, then the text of
a message). Perhaps as a result of that, the fields at the
beginning of the message have taken on the character of a
delivery "trace", while the fields at the end of the block
typically were inserted by the client.
Some people who talked to me felt very strongly that additions
to the trace section in the right place were more in keeping with
what's considered allowable header modifications, while inserting
in the middle, with no way of tracking who did that, should only
happen if explicitly requested. As one of the people who occasionally
has to decipher the traces to figure out where some problem originates,
that made intuitive sense to me.
and:
A message modified by addheader or deleteheader MUST NOT
be considered the same as the original message unless it
matches the original message exactly.
For example, the following code fragment
keep;
addheader "X-Flavor: vanilla"
keep;
files two messages, not one.
I see where that is coming from. If you do a "keep" after changing
the header, it's assumed that you really meant it; and if weeding out
duplicate "keep" operations prevents that, then you have lost some
change. However: you have not lost the message unless some prior
action had deliberately caused it; any weeding out represents a script
error rather than loss of the message, so I am not sure this is an
improvement.
In an ambiguous and possibly erroneous situation, I prefer to err
on the side of shorter explanations and more saved information.
One alternative: make a note that the message has changed, and if so,
inhibit any subsequent de-duplication logic on the next action only.
That seems difficult to explain. I don't see why the first of
any number of duplicate fileinto's etc. should receive preferential
treatment.
BTW, in the absence of a "changed" flag, this new philosophy might also
imply that implicit keep is once again turned on (if it had been
turned off). Whether it is or is not is now ambiguous.
It is my intention that the implicit keep should _not_ be restored
after a header modification. I'll weaken the section on weeding out
duplicates to (hopefully) be less likely to inspire that idea.
And.. what about replaceheader?
As mentioned in section 9.1, replaceheader is no longer in the draft.
My implementation still has it, but it's a vendor-specific extension
after encountering determined opposition from some members of the
work group. If you implement it, the rules with respect to duplication
would be the same as for add- and deleteheader.
Jutta <jutta(_at_)sendmail(_dot_)com>