On Thu, Jan 15, 2004 at 08:35:51PM -0800, Philip Guenther wrote:
"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.
I didn't say that last phrase, so it's hard to respond to it. An agent
that follows this draft in either of its last two forms is not
crippled. I didn't even say (or intend to say, though I think I can
see how it got inferred) that the draft is "crippled" by the default
being the beginning rather than the end. I was talking about the line
of reasoning leading up to this point: i.e., that there is a
precedent set by MTAs prepending headers, and MUAs appending them. I
said that a SIEVE filter (certainly by one definition) can commonly be
a local agent acting on behalf of the mailbox owner. I said that I
could imagine another mode where it was acting more MTA-like, and that
perhaps a mode could be defined where the filter was not allowed such
a free hand (since it would be operating on mail *other* than that
owned by the person directing it). (In fact I think it would be
useful to make that role distinction when talking about what a filter
can and can not do.) I then said that that hypothetical mode should
not be the one that dictated the way drafts (or agents) were written;
if it were, it would be restrictive (i.e., crippling) for the LDA
role. It's a few steps back from that philosophical observation to
the specific item in the draft, sorry about the apparent connection.
Can you refute the previously provided
reasons for defaulting to prepending or otherwise provide a
countervailing argument?
Not "refute" -- no. Disagree with, yes, but really only mildly, and
I've outlined why a few times. If I wasn't clear I can try again, but
I doubt that people need to have me belabor it. For reasons I've
already given I feel that appending is better for a final delivery
agent. A draft stage is where one puts in these opinions so I am:
obviously other(s) felt similarly motivated, though in the other
direction, between the last two drafts. I would even suggest having
the default be implementation-dependent, and if one wanted to be
explicit one would use :first or :last .
... [regarding replaceheader]
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.
Yeah- that's one reason I was wondering where this discussion had
taken place up to now (between the last two drafts, that is). If
you've been involved in discussing it you have a different perspective
than I, who only knows that it is gone and wonders why, and wonders
what will become of it. I certainly understand the goal of pragmatism,
especially if there's conflict over "replaceheader". But it's also
a good goal to have an extension that encapsulates all related functions.
Yours,
-mm-