"Mark E. Mallett" <mem(_at_)mv(_dot_)mv(_dot_)com> writes:
... [regarding default placement of added header fields]
My contention is that in a local
delivery mode, one ought to be able to do to the mail what one wants
to do to it. As I said, I could see where there could be more
constraints on a filter that was operating in other than local
delivery mode. However I think it would be a shame to cripple a local
delivery agent for that reason: it would be better to define an
operational mode that had more constraints if one wanted.
Given that the draft *does* provide a means to do what you want
(place the added header field at the end of the header instead of
the beginning), calling an agent that follows the draft 'crippled'
seems like pure hyperbole. Can you refute the previously provided
reasons for defaulting to prepending or otherwise provide a
countervailing argument?
... [regarding replaceheader]
There certainly could be situations where replaceheader can't
do what you want: but that's no reason to remove it.
It wasn't removed because it didn't do what was wanteded; it was
removed because people felt it too complicated and had various
hairy problems (for example, involving rfc2047-encoded words).
...
That's not really what I was getting at. I'd want to see
"replaceheader" retained in the draft, even if it's as a "MAY" with a
separate capability name (a la the "envelope" precedent) rather than
punted like that with no chance for uniform implementation of optional
facilities. Certainly anything can be incorporated in a private
implementation, but that's not this discussion.
The question isn't whether replaceheader should be described in an
rfc. The question is whether addheader and deleteheader should be
held up while the people try to reach consensus on replaceheader.
It's one thing to combine separable extensions in a single document
when they're all ready to go at the same time, but that isn't true
here.
Philip Guenther
guenther(_at_)sendmail(_dot_)com