On Wed, Jan 07, 2004 at 04:53:37PM -0800, Jutta Degener wrote:
Hi- thanks for the responses. Sorry it's been over a week.
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.
I don't look at it that way, myself. Not to mention that I don't
think "ease" has anything to do with it in a sieve application: that
application is manipulating the message, and so putting the header one
place is no more difficult than putting it another. I do follow that
you are explaining why adding at the beginning is a precedent. However
it's a precedent for a different context.
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.
I would disagree with those people :-) We're not talking MTA here nor
are we talking about trace fields: we're talking about manipulating a
message where there is the presumption that one has the right to do
so, in the same way that one can go into a text editor and manipulate
it. Admittedly there is a quasi- area where a sieve filter can be
applied in a forwarding context. But in the (more common) case where
the filter is operating on behalf of the recipient, I would want to be
able to do the changes I want done. (kind of a tautology there.)
Regarding the duplicate "keep" after a changed message:
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.
I think the shortest explanation would be not to introduce the
"changed message" concept. One might say that if one has done a "keep"
then changed the message then did a "keep" again, an error can occur no
matter how you look at it, so keeping the traditional de-duplication
logic is better. I find this new potential for duplicate filings
disturbing.
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.
Because of what I said in the original message:
On the flip side, anyone who has depended on duplicate "keep"
operations being weeded out will be surprised by having two
messages filed. Likely if you have done a "keep" in the same
code area as the addheader, you probably do want the second
copy. But in another case? Not so clear, especially if you have
done something else with the message after changing the header.
I guess I wasn't clear with that. I was trying to say that it's likely
that if you do an immediate "keep" right after the addheader, you
probably meant to keep the changed message. But if there's a "keep"
far away further in the script, you probably want the de-duplication
to happen (i.e., supress that other far-away "keep"). I was trying to
invent some reason why you would really want the second keep to file
the message again (after a change), and contrast that with what I
consider to be the standard case where you don't want it to happen, and
then come up with a generic rule to infer intent as expressed in the
language. Perhaps a better inference would be: if there is a header
modification followed by an action within the same code block (block
enclosed by curly braces), ignore the de-duplication and perform the
action anyway.
The bottom line is that I don't like the part where normal de-duplication
is inhibited. I'd vote for getting rid of the new stuff about the changed
message, and if that prevents the filing of a changed message, fix the
script :-)
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.
Hmm- certainly seems like replaceheader is a convenient shortcut
for "deleteheader" and "replaceheader" -- except that you lose
position, which I consider a loss (for reasons given above).
(As I recall, earlier discussion included some finer control over
header placement; again, losing that is, it seems to me, a loss.)
This response brings up a couple new questions too, which can only
be explained by my ignorance I'm afraid, but here goes:
Is there a separate work group for "editheader"? I had thought from
the archives that it open for discussion here. What other work groups
are there?
How does a vendor-specific extension get specified vis-a-vis "require" ?
And in that light, could not the rules for duplication also become
"vendor-specific" ?
Yours,
mm