Subject: [Gen-art] Gen-ART LC Review of draft-freed-sieve-date-index-11

From: Ben Campbell <[email-masked]>
Date: Fri, 23 May 2008 13:47:42 -0500

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

Can you mention the reason that the date test can only apply to one  
header field at a time?

Last paragraph, last sentence: "... the last one that appears should  
be used."

Is that a normative SHOULD?

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.

Section 6.1, section title:

Section title is "Examples", but I only see one example :-)

Thanks!

Ben.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Ned Freed <[email-masked]>
Date: Sat, 24 May 2008 17:08:30 -0700 (PDT)

> 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

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.

> Is that a normative SHOULD?

Sure, why not?

> of default time zone. It might help to explicitly state that in this

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 title is "Examples", but I only see one example :-)

Fixed.

				Ned

---

From: Ben Campbell <[email-masked]>
Date: Sun, 25 May 2008 13:10:15 -0500

Hi,

Your response resolves all of my comments. Details inline.

Thanks!

Ben.

> specification either as an implementor or user will necessarily know  

Okay

> of the test simple and obvious.

I think that's good enough, thanks.