Again, my apologies to the working group for the long delay in
responding to the comments from the WGLC on this draft.
I'm not going to list the trivial editorial changes here.
Matthew Elvey wrote:
Tests and actions such as "exist" or "header" that examine
The test is "exists", not "exist". "Exists" and "header" are both
tests, and actions don't examine. Therefore, I suggest:
Tests such as "exists" or "header" that examine
Instead of restricting it to tests, I've added an action that
examines header fields:
Tests and actions such as "exists", "header", or "vacation"
[VACATION] that examine header fields MUST examine the current
state of a header as modified by any actions that have taken
place so far.
Mark E. Mallett wrote:
use of [KEYWORDS] and "Syntax:" label for the definition of action
I think labels are plural, so it ought to read "... labels for
definitions of ..."
Not quite: the correct parse groups from "Syntax:" to the end of
the sentence. Inserting a 'the' clears it up, I think:
Conventions for notations are as in [SIEVE] section 1.1, including
use of [KEYWORDS] and the "Syntax:" label for the definition of
action and tagged arguments syntax.
(I.e., the conventions include "use of [KEYWORDS]" and "use of the
Syntax: label for...syntax")
Just the obligatory comment about using "example.tld" even though "tld"
isn't a real top level domain name today.
I've changed "foo.tld" to "foo.example.com":
if not header :contains "X-Sieve-Filtered"
["<kim(_at_)job(_dot_)example(_dot_)com>",
"<kim(_at_)home(_dot_)example(_dot_)com>"]
{
addheader "X-Sieve-Filtered"
"<kim(_at_)job(_dot_)example(_dot_)com>";
redirect "kim(_at_)home(_dot_)example(_dot_)com";
}
Should there be remarks about the potential damage that can be
caused to the MIME structure of a message (e.g. by removing/adding
MIME header fields)?
With regards to the effect this can have on the sieve processing
itself, see below. Or were you suggesting a "this tool is sharp:
poking self in eye may harm depth preception" warning?
Nigel Swinson wrote:
Is it worth making it explicit that if deleteheader can't find any
matching headers then this isn't an error?
I've added the following as the last paragraph of section 4:
It is not an error if no header fields match the conditions in
the deleteheader action or if the :index argument is greater
than the number of named header fields.
I think we are saying that editheader does not cancel the implict
keep (certainly this makes sense), but I don't think we've been
very clear about it. I liked the clarity of what was said in the
vacation draft: "Vacation does not affect Sieve's implicit keep
action."
I've added "The addheader action does not affect Sieve's implicit
keep." to section 3 and a similar statement for deleteheader to
section 4.
Cyrus Daboo wrote:
4.5: replace ';' at end of paragraph with '.'. Add 'Example:' as
new line after paragraph.
Given the text following the example, I went with:
<...> The counting happens
before the <value-patterns> match, if any. For example:
deleteheader :index 2 :contains "Received" "via carrier-pigeon"
deletes the second "Received:" header field if it contains
<...>
Alexey Melnikov wrote:
Actions that create messages in storage or in transport to
MTAs MUST store and send messages with the current set of
header fields.
I am not sure I understand what is "in transport to MTAs", is this
trying to say "in MTA's queue"?
It's trying to say that if you do something like forward the message,
the forwarded content reflects any changes. Would it be clearer
if that sentence was simplified to
Actions that store or send the message MUST do so with the
current set of header fields.
?
MUST only file one message. It is up to the implementation
to pick which of the redundant "fileinto" or "keep" actions is
executed, and which ones are ignored.
I am not sure I like this, even though I understand the motivation.
When Ned and Ken has discussed imapflags they agreed that the last
keep wins (i.e. the current flags at the time of the last keep).
Consistency is a good thing. And the MUST at the beginning of
section 5 seems to suggest the same.
I just reviewed the discussion on the from when it was changed to
this and the thought from at least a couple people at the time was
that leaving it open would ease implementation by making it agnostic
to the "evaluate as you go" vs "evaluate all at the end" choice.
Is there consensus to change this again?
(Previous to that, it called for *no* duplicate supression.)
Arnt Gulbrandsen wrote:
Another minor point: If a message is rejected after being modified,
which version of the message should be sent to the bounce address,
the original message or the one with a modified header?
The one with the modified header. This was covered by the "Actions
that create messages..." sentence in section 5, which I'm changing
to the "Actions that store or send the message..." sentence mentioned
above.
Now for the two ugly issues:
Ned Freed wrote:
I think we need weasel words to the effect that changing the meaning
of the MIME structure with addheader may not produce results that
actually affect subsequent body or other MIME-related tests.
(Also commented on by Arnt Gulbrandsen and William Leibzon)
Does the following, added after the first example in section 5,
give the correct dose of leeway?
However, if the presence or value of a header field affects how
the implementation parses or decodes other parts of the message,
then for the purposes of that parsing or decoding the implementation
MAY ignore some or all changes made to those header fields. For
example, in an implementation that supports the [BODY] extension,
"body" tests may be unaffected by deleting or adding Content-Type
or Content-Transfer-Encoding header fields. This does not rescind
the requirement that changes to those header fields affect direct
tests; only the semantic side effects of changes to the fields
may be ignored.
If not, where did I miss the turn?
Ned Freed wrote:
[Mark Mallett wrote:]
I really miss "replaceheader" and I think it's a huge mistake not to
include it. "replaceheader" was the only way that one could rename a
header in place, which may have been one source of the objections to it,
but which I found to be the root of its value. Perhaps a compromise
could be to include "replaceheader" as an optional additional capability
name in this document (the way that "fileinto" is included in the base
spec).
FWIW, I miss it too.
I'm not enthralled by the idea of bringing replaceheader back into
the draft at this late date, especially given how the complexity
issues were never resolved. I somehow suspect that the ensuing
discussion would be a cut-and-paste of the one that took place two
years ago.
Therefore, I am pushing back on these wistful thoughts.
Philip Guenther