Subject: Informal Working Group Last Call on draft-freed-sieve-date-index-04.txt

From: Alexey Melnikov <[email-masked]>
Date: Tue, 06 Mar 2007 12:58:48 +0000

We would like to draw your attention to the following draft:

<http://www.ietf.org/internet-drafts/draft-freed-sieve-date-index-04.txt>

A three week informal last call of this document starts today on March 
6th 2007 and ends on March 27th 2007 at 6 pm EST.

Please review this document and send issues to the list or directly to 
the author. In the latter case please CC both WG chairs, so that we can 
track issues.

NB If you do review this document, but have no issues or comments, 
please send both co-chairs (or the list) an email to indicate you have 
looked at it. This will allow the chairs to gauge the scope of reviews 
of this document to aid in our determination on whether to send it to 
the IESG. Thanks.

--
Cyrus Daboo and Alexey Melnikov
SIEVE WG chairs

---

From: Dave Cridland <[email-masked]>
Date: Tue, 06 Mar 2007 13:58:43 +0000

> <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.

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.

I'd expect:
	address :index 2 :domain ["to"] ["mrocheck.com"]

to match for this message, for example.

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.".

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.

4) The draft utterly lacks any examples. How can I possibly implement 
it unless I have badly written examples to perpetuate errors from? ;-)

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").

Feel free to correct my comments if I've merely missed things on a 
read-through.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 6 Mar 2007 15:16:40 +0100

> that the address header fields - To, CC, BCC - are only allowed once 

Resent-To and its friends may occur any number of times. (Its friends 
are not my friends.)

Arnt

---

From: Ned Freed <[email-masked]>
Date: Tue, 06 Mar 2007 10:19:09 -0800 (PST)

> 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).

> that the address header fields - To, CC, BCC - are only allowed once

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.

> to match for this message, for example.

Again, that's not the intent. I'll add a paragraph that makes this clear.

> 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"?

> 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.

> 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.

> works for all of them, I think, except "julian", for which you need

How about you suggest some text for this?

				Ned

---

From: Dave Cridland <[email-masked]>
Date: Tue, 06 Mar 2007 22:02:21 +0000

> about possible situations involving multiple blocks of resent- 
Right - I was beginning to think so from Arnt's comment about 
Resent-*.

I think there's lots of utility in being able to run several tests on 
a particular address in a header field, too, but if that's not what 
this specification is trying to do, that's fine. I just read 
"address" and ":index", and thought it probably was.

> wording than what's there now. How about "as controlled by"?
Yes, much better.

> operating on structured fields. I'll simply remove the word 
I have to admit I read "structured" as implying one formally defined 
to hold a date somewhere. Whereas I'd expect that, in principle, 
"X-Foo-Date: ..." wouldn't be structured per se. Removal of 
"structured" would confuse me less.

> adding examples at this point.
I'll take that as a public call for useful examples, which'd also be 
a useful way of validating the draft.

> How about you suggest some text for this?

Not all comparators are suitable with all date-part arguments. In 
general, the date-parts can be compared and tested for equality with 
either "i;ascii-casemap" (the default) or "i;octet", but there are 
two exceptions:

"julian" - The Modified Julian Day is an integer, and may or may not 
have leading zeros. As such, it needs to be used with 
"i;ascii-numeric".

"std11" - This is case-insensitive, and therefore "i;ascii-casemap" 
needs to be used.

"year", "month", "day", "date", "hour", "minute", "second" and 
"weekday" all use fixed-width string representations of integers, and 
can therefore be compared with "i;octet", "i;ascii-casemap", and 
"i;ascii-numeric" with equivalent results.

(And yes, avoiding any RFC2119 language there was intentional - 
script authors *can* compare iso8601 values using "i;ascii-numeric" 
if they want.)

Dave.

---

From: Ned Freed <[email-masked]>
Date: Tue, 06 Mar 2007 15:39:03 -0800 (PST)

> a useful way of validating the draft.

Yes, that would be great.

> script authors *can* compare iso8601 values using "i;ascii-numeric"

Nice. I've added it more or less verbatim. Thanks!

				Ned