Re: Gen-ART LC Review of draft-freed-sieve-date-index-11

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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

> 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]