ietf-mta-filters
[Top] [All Lists]

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

2007-03-06 15:12:09

On Tue Mar  6 18:19:09 2007, Ned Freed wrote:
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).


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.

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


Yes, much better.


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.


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.


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.


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


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?

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.
--
Dave Cridland - mailto:dave(_at_)cridland(_dot_)net - 
xmpp:dwd(_at_)jabber(_dot_)org
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade