Re: draft-degener-sieve-editheader-01.txt
"Mark E. Mallett" <mem@mv.mv.com> Wed, 07 January 2004 23:03 UTC
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07N34ib079821 for <ietf-mta-filters-bks@above.proper.com>; Wed, 7 Jan 2004 15:03:04 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i07N34eo079820 for ietf-mta-filters-bks; Wed, 7 Jan 2004 15:03:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f
Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.10/8.12.8) with SMTP id i07N33ib079813 for <ietf-mta-filters@imc.org>; Wed, 7 Jan 2004 15:03:03 -0800 (PST) (envelope-from mem@mv.mv.com)
Received: (qmail 22983 invoked from network); 7 Jan 2004 18:03:04 -0500
Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 7 Jan 2004 18:03:04 -0500
X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net
Received: (qmail 1596 invoked by uid 101); 7 Jan 2004 18:03:04 -0500
From: "Mark E. Mallett" <mem@mv.mv.com>
Date: Wed, 07 Jan 2004 18:03:04 -0500
To: ietf-mta-filters@imc.org
Subject: Re: draft-degener-sieve-editheader-01.txt
Message-ID: <20040107230304.GA7713@iridium.mv.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Sender: owner-ietf-mta-filters@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe>
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. 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. 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. One alternative: make a note that the message has changed, and if so, inhibit any subsequent de-duplication logic on the next action only. So the next "keep" would succeed unless (e.g.) "redirect" were done first. This would introduce a new "changed" flag, but this new text introduces that concept anyway. That's not as perfect as, say, views, but it's no worse than the suggested one. 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. And.. what about replaceheader? I would assume that any change made by replaceheader would also cause the message to be considered "different" -- but that new text explicitly calls out "editheader" and "deleteheader" without mentioning "replaceheader," so it seems deliberate. Yours, mm
- Re: draft-degener-sieve-editheader-01.txt Jutta Degener
- Re: draft-degener-sieve-editheader-01.txt Mark E. Mallett
- Re: draft-degener-sieve-editheader-01.txt Mark E. Mallett
- Re: draft-degener-sieve-editheader-01.txt Jutta Degener
- Re: draft-degener-sieve-editheader-01.txt Nigel Swinson
- Re: draft-degener-sieve-editheader-01.txt Jutta Degener
- Re: draft-degener-sieve-editheader-01.txt Mark E. Mallett
- Re: draft-degener-sieve-editheader-01.txt Philip Guenther
- Re: draft-degener-sieve-editheader-01.txt Mark E. Mallett
- Re: draft-degener-sieve-editheader-01.txt; "refus… Matthew Elvey (FM)
- Re: draft-degener-sieve-editheader-01.txt; "refus… Cyrus Daboo
- Re: draft-degener-sieve-editheader-01.txt; "refus… Cyrus Daboo
- Re: draft-degener-sieve-editheader-01.txt; "refus… Jutta Degener
- Re: draft-degener-sieve-editheader-01.txt; "refus… Nigel Swinson
- Re: draft-degener-sieve-editheader-01.txt; "refus… Mark E. Mallett