Philip Guenther wrote:
FYI, I have already submitted rev -01 incorporating the changes
discussed in Minneapolis. I didn't roll them into my resubmission of
-00 to avoid confusing people about what it contained.
Responding to your comments out of order...
Michael Haardt <michael(_dot_)haardt(_at_)freenet-ag(_dot_)de> writes:
...
Address Test For Multiple Addresses Per Header
A header may contain multiple addresses. RFC 3028 does not explicitly
specify how to deal with them, but since the "address" test checks if
anything matches anything else, matching one address suffices to
satify the condition. That makes it impossible to test if a header
contains a certain set of addresses and no more, but it is more logical
than letting the test fail if the header contains an additional address
besides the one the test checks for.
Cyrus had forwarded your comment on this to me some time ago, so -01
includes this sentence in section 5.1:
Whether there are other addresses present in the header doesn't
affect this test; this test does not provide any way to
determine whether an address is the only address in a header.
I like that.
String Arguments
There has been confusion if the string arguments to "require" are to be
matched case-sensitive or not. I suggest to match them with
the match type ":is" (default, see section 2.7.1) and the comparator
"i;ascii-casemap" (default, see section 2.7.3). The RFC defines the
command defaults clearly, so any different implementations violate RFC
3028. The same is valid for comparator names, also specified as strings.
Since "require" is not described as taking MATCH-TYPE or COMPARATOR
arguments, I don't see how the defaults of sections 2.7.1 and 2.7.3 can
be read as applying. Whether comparator names are case-sensitive is up
to the draft defining the collation registry: if it says they are, then
both comparator strings *and* the string argument to "require" *must* be
treated as case-sensitive so that all comparator names can be
specified.
According to draft-newman-i18n-comparator-03.txt, collation names may
contain both uppercase and lowercase letters. I see nothing in the
draft that would have them treated as case-insensitive. Given that, I
don't see how sieve can specify those strings to be case-insensitive.
In this case I think it might be better to explicitly say that the
require parameter is case-sensitive.
Strings Containing Header Names Or Envelope Elements
RFC 3028 does not specify what happens if a string denoting a header field
or envelope element does not contain a valid name, e.g. it contains a
colon for a header or it is not "from" or "to" for envelopes.
Look closer. 2.4.2.2p2:
A header name never contains a colon. The "From" header refers
to a line beginning "From:" (or "From :", etc.). No header
will match the string "From:" due to the trailing colon.
As for "envelope", I think the current phrasing ("If one of the
envelope-part strings...") could be read to imply that envelope-part
strings other than "from" and "to" are simply ignored. However, that's
certainly not as clear as 2.4.2.2's statement for bogus header names.
(Indeed, I just checked and Sendmail's implementation gives a syntax
error on envelope-part strings other than "from" and "to".)
I suggest
generating an error instead of ignoring the header field in order to
ease script debugging, which fits in the common picture of Sieve.
<editor-hat off>
I am opposed to reversing the existing statement in 2.4.2.2, as the
existing text is quite clear and unambiguous.
<chair-hat off>I agree</chair-hat off>
I am mildly in support of making it an error for envelope as a
clarification, but think more people should speak to the point.
<chair-hat off>I agree</chair-hat off>
<editor-hat on>