Subject: [Gen-art] Gen-ART IETF LC review of draft-ietf-imapext-i18n-14

From: Ben Campbell <[email-masked]>
Date: Sun, 27 Jan 2008 14:08:53 -0600

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-ietf-imapext-i18n-14
Reviewer: Ben Campbell
Review Date:  2008-01-27
IETF LC End Date: 2008-01-29

Summary:

This draft is almost ready for publication as a proposed standard.  
There are editorial issues that should be considered prior to  
publication.

Comments:

In general this draft is very easy to read and understand. I believe  
my comments are all editorial, although the first one might be  
considered substantive by some.

Sections 5 and 9 entirely consist of problem identification, guidance  
to implementors of IMAP in general, and even some possible best  
practices, much of which are not directly related to the extensions  
being defined in this draft. While I agree it is valuable information,  
I wonder if it is more appropriate to include them in a standards  
track RFC, or to remove them to one or more separate informational  
RFCs. I do not mean to dispute the will of the working group; I merely  
bring it up to make sure people have thought about it. That is, it's  
okay with me if the answer is "we've thought about it, and prefer to  
keep it the way it is".

Section 4.3, paragraph 1:

Plural subject "servers" does not agree with "advertises" and "doesn't  
support" later in the sentence.

Section 4.4. paragraph 1:

Plural subject "servers" does not agree with "advertises" and "doesn't  
support" later in the sentence.

Section 4.5, last paragraph:

I assume this paragraph was not intended to be normative, given the  
lower-case "should"s. I call attention to it only to make sure that is  
the authors' intent.

Section 4.6, 3 paragraphs from end: " <<Add an example>>"

Do you still intend to add the example, or is the text obsolete? I  
think an example would help.

Finally, IDNITS returns the following comments, that I include without  
prejudice:

>   Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt 
> :
>    
> ----------------------------------------------------------------------------
>
>   == The page length should not exceed 58 lines per page, but there  
> was 17
>      longer pages, the longest (page 2) being 60 lines
>
>   == It seems as if not all pages are separated by form feeds -  
> found 0 form
>      feeds but 18 pages
>
>
>   Checking nits according to http://www.ietf.org/ID-Checklist.html:
>    
> ----------------------------------------------------------------------------
>
>   ** There are 5 instances of too long lines in the document, the  
> longest one
>      being 2 characters in excess of 72.
>
>
>   Miscellaneous warnings:
>    
> ----------------------------------------------------------------------------
>
>   == The copyright year in the IETF Trust Copyright Line does not  
> match the
>      current year
>
>
>   Checking references for intended status: Proposed Standard
>    
> ----------------------------------------------------------------------------
>
>      (See RFC 3967 for information about using normative references to
>      lower-maturity documents in RFCs)
>
>   == Outdated reference: A later version (-12) exists of
>      draft-daboo-imap-annotatemore-11
>

Thanks!

Ben.

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