On Tue Mar 6 12:58:48 2007, Alexey Melnikov wrote:
>
> We would like to draw your attention to the following draft:
>
> <http://www.ietf.org/internet-drafts/draft-freed-sieve-date-index-04.txt>
Some comments based on a fairly rapid first-time read-through from a
script author's perspective:
1) In the abstract, concerning index, I note it refers to "specific
instances of header fields" - but it's presumably also capable of
limiting to specific addresses.
No, that's not the intent at all. :index counts multiple occurances of header
fields, not whatever is in those fields.
Of course you could define a parameter that selects a particular address out of
an address list for testing, but :index isn't it. I also have to say that I see
no reason to have such a capability, whereas the abiltiy to specify the header
field you're testing is clearly useful even for address tests (again, think
about possible situations involving multiple blocks of resent- fields in the
header).
Similarly, section 6 also implies that the address test operates on a
header field rather than on an address, which seems odd. I believe
that the address header fields - To, CC, BCC - are only allowed once
in a message header.
Um, not exactly. While it is true that RFC 2822 says you should only have one
of each of these fields, there are plenty of other standard fields that can
contain addresses, such as resent-to, that can appear multiple times. (And this
doesn't even consider nonstandard fields containing addresses.) I will also
point out that just because RFC 2822 says this doesn't mean the rule isn't
violated routinely (RFC 822 contains no such prohibition, BTW), and sieve needs
to be able to process the stuff people actually do, not just what the standards
say is OK to do.
I'd expect:
address :index 2 :domain ["to"] ["mrocheck.com"]
to match for this message, for example.
Again, that's not the intent. I'll add a paragraph that makes this clear.
2) Section 4 uses the phrase "[...] as modified by the comparator and
match keywords." - this doesn't ring true with my understanding of
comparators, perhaps a better way of phrasing this would be, "[...]
according to the comparator and match keywords.".
I agree the wording isn't great, but I also think according is actually worse
wording than what's there now. How about "as controlled by"?
3) Section 4 implies that it only operates on structured header
fields. I suspect it might be useful to allow it to be used on an
unstructured header field that happens to contain a string which
forms a date. The last paragraph appears to imply that, but the use
of the phrase "structured headers" contradicts.
Such a field is then by definition not unstructured. I don't see much point in
calling this out, but there's also little point in referring to this test
operating on structured fields. I'll simply remove the word "structured" from
the sentence.
4) The draft utterly lacks any examples. How can I possibly implement
it unless I have badly written examples to perpetuate errors from? ;-)
I'll consider adding some, but I'm more interested in getting this done than in
adding examples at this point.
5) Do you think anyone will figure out that, if using
i;ascii-numeric, "2007-03-06" will be considered equal to
"2007-01-01"? It might be a good idea to make a paragraph or two
noting which comparators are suitable for which operations. (i;octet
works for all of them, I think, except "julian", for which you need
"i;ascii-numeric").
How about you suggest some text for this?
Ned