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