Hi,
Your response resolves all of my comments. Details inline.
Thanks!
Ben.
On May 24, 2008, at 7:08 PM, Ned Freed wrote:
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-freed-sieve-date-index-11
Reviewer: Ben Campbell
Review Date: 2008-05-23
IETF LC End Date: 2008-05-28
IESG Telechat date: (if known)
Summary:
This document is basically ready for publication as a draft standard.
I have a few minor comments which I consider optional to address.
Comments:
Section 4:
Does it make sense to add a reference for ":is" and "i;ascii-
casemap"?
No. These are both core Sieve items defined in the Sieve base
specification.
Anyone with enough familiarity with Sieve to actually make use of this
specification either as an implementor or user will necessarily know
what these
are.
Okay
Can you mention the reason that the date test can only apply to one
header field at a time?
Date-time values specify a point in time. When you test one you're
looking to
see if it meets certain criteria: Before a given time, after a given
time, or
within some interval. The results become ambiguous the minute you
allow the
test to consider multiple dates - someimtes you'd want it to succeed
only if
all the dates passed the test, other times if any passed - so the
test is
constructed so only a single date is selected.
I'm a long way from convinced such a longwinded explanation is worth
adding,
however. Instead I'll just put in a point about this limit keeping
the meaning
of the test simple and obvious.
I think that's good enough, thanks.
Last paragraph, last sentence: "... the last one that appears should
be used."
Is that a normative SHOULD?
Sure, why not?
Section 4.1, time-zone syntax:
I assume the 4 digits are hhmm, as mentioned later in the discussion
of default time zone. It might help to explicitly state that in this
section.
AFAIK there is no zone offset defined anywhere in email that works
any other
way, but adding an explanation of it can't hurt.
Section 6.1, section title:
Section title is "Examples", but I only see one example :-)
Fixed.
Ned
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf