Re: [EAI] Gen-ART review of draft-ietf-eai-imap-utf8-07

[<Black_David at emc.com>]

Alexey,

> >- The header upconversion behavior specification for non-UTF-8
> >	mailstores appears to be incomplete.
...
> Actually no, I believe this is already fully specified in RFC 
> 3501 (base IMAP spec), Section 6.4.4:

I concur - this is not an issue.  Thanks for the pointer to the
relevant portion of RFC 3501.

> >- The recommendation to support MIME header upconversion for
> >	"Other widely deployed MIME charsets" strikes me as
> >	too vague to be useful guidance to implementers.
...
> I believe John Klensin has adequately responded to this point.

John has thoroughly demolished the change I suggested, but I
don't think that demolition resolves this concern, as the original
text remains vague.

OTOH, this draft is intended to be an Experimental RFC - would
it be reasonable to say that determining which charsets should
be upconverted is part of the experiment?

> >While not strictly a security consideration, it would be useful for
> >section 11 to point out the potential for user confusion caused by
> >SEARCH command match strings that have different UTF-8
representations
> >but display identically or similarly (strings that look like they
> >should match don't).

That was a nit - leaving the Section 11 text unmodified is fine,
as Section 11 already references RFC 3629.

Thanks,
--David
 

> -----Original Message-----
> From: Alexey Melnikov [mailto:alexey.melnikov at isode.com] 
> Sent: Tuesday, September 01, 2009 5:36 PM
> To: Black, David
> Cc: presnick at qualcomm.com; chris.newman at sun.com; 
> gen-art at ietf.org; harald at alvestrand.no; lee at cnnic.cn; ima at ietf.org
> Subject: Re: Gen-ART review of draft-ietf-eai-imap-utf8-07
> 
> Hi  David,
> Thank you for your detailed review.
> 
> Black_David at emc.com 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-ietf-eai-imap-utf8-07
> >Reviewer: David L. Black
> >Review Date: August 31, 2009
> >IETF LC End Date: August 31, 2009
> >IESG Telechat Date: September 10, 2009
> > 
> >Summary:
> >
> >This draft is on the right track, but has open issues, described
> >in the review.
> >
> >The draft appears to be in good shape, although one has to be an
> >IMAP expert to understand all of its implications (and I am not
> >an IMAP expert).  I found two open issues:
> >
> >- The header upconversion behavior specification for non-UTF-8
> >	mailstores appears to be incomplete.
> >- The recommendation to support MIME header upconversion for
> >	"Other widely deployed MIME charsets" strikes me as
> >	too vague to be useful guidance to implementers.
> >
> >Major issues:
> >
> >Section 3.2, upconversion behavior specification appears to be
> >incomplete:
> >
> >   If the mailstore is not UTF-8
> >   header native and the SELECT or EXAMINE command with UTF-8 header
> >   modifier succeeds, then the server MUST return results as if the
> >   mailstore was UTF-8 header native with upconversion 
> requirements as
> >   described in Section 8.  
> >
> >What happens if a header that is not upconverted is accessed with
> >a UTF-8 comparison string (e.g., by SEARCH)?  I presume that no
> >matches occur courtesy of the charset mismatch, but that needs to
> >be explained, as it will be a surprise to users.
> >
> Actually no, I believe this is already fully specified in RFC 
> 3501 (base 
> IMAP spec), Section 6.4.4:
> 
>       The OPTIONAL [CHARSET] specification consists of the word
>       "CHARSET" followed by a registered [CHARSET].  It indicates the
>       [CHARSET] of the strings that appear in the search criteria.
>       [MIME-IMB] content transfer encodings, and [MIME-HDRS] 
> strings in
>       [RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing
>       text in a [CHARSET] other than US-ASCII.  US-ASCII MUST be
>       supported; other [CHARSET]s MAY be supported.
> 
> So any of the recognized charsets will be decoded by the 
> server and the 
> right thing would happen.
> 
> >Section 8 lists a number of 8859 character sets for which 
> upconversion
> >of MIME headers MUST be supported, and then says "Other 
> widely deployed
> >MIME charsets SHOULD be supported."  How does an implementer figure
> >out which character sets those would be?  As an alternative, 
> I suggest
> >saying something along the lines of: any server-supported character
> >set that is a superset of ASCII should be supported for upconversion.
> >That probably leads to fewer client surprises caused by UTF-8 not
> >working as expected.
> >  
> >
> I believe John Klensin has adequately responded to this point.
> 
> >Minor issues:
> >
> >Section 3.1, next to last paragraph needs a couple of RFC 2119
> >keywords:
> >
> >   Mailbox
> >   names must comply with the Net-Unicode Definition (section 2 of
> >MUST >-->^^^^
> >
> >   [RFC5198]) with the specific exception that they may not contain
> >MUST NOT >----------------------------------------->^^^^^^^
> >
> >   control characters (0000-001F, 0080-009F), delete (007F), line
> >   separator (2028) or paragraph separator (2029).
> >
> Agreed. I've entered these as RFC Editor notes.
> 
> >The ABNF in this draft is extensions to ABNF specified elsewhere.
> >I hope that the combined ABNF grammars have been run through an
> >ABNF checker, but didn't see any mention of that in the IESG
> >comment log.
> >
> Yes, both Harald Alvestrand and myself checked the ABNF.
> 
> >This would normally be covered by a shepherd's
> >report, but I did not see one.
> >
> This is coming.
> 
> >Section 7 recommends that all IMAP clients be modified to display a
> >clear error when the server advertises UTF8=ONLY.  What's the
> >expected behavior of existing, unmodified clients?
> >  
> >
> Such clients will not be using the UTF8 parameter to SELECT/EXAMINE 
> (mailbox opening) commands, so they will fail to do anything 
> useful. But 
> this is to be expected.
> 
> >Nits/editorial comments:
> >
> >Section 2 ought to introduce what's being added to the protocol.
> >Adaptations of the first two sentences in Section 10 (IANA
> >Considerations) would suffice.
> >
> >While not strictly a security consideration, it would be useful for
> >section 11 to point out the potential for user confusion caused by
> >SEARCH command match strings that have different UTF-8 
> representations
> >but display identically or similarly (strings that look like they
> >should match don't).
> >  
> >
> I will let editors respond/address these 2 comments.
> 
> > 
> >-------------------------------------------------------------
> -----------
> >----
> >
> >  ** There is 1 instance of too long lines in the document, 
> the longest
> >one
> >     being 14 characters in excess of 72.
> >
> >
> >  Miscellaneous warnings:
> > 
> >-------------------------------------------------------------
> -----------
> >----
> >
> >  == The document seems to lack the recommended RFC 2119 boilerplate,
> >even if
> >     it appears to use RFC 2119 keywords -- however, there's 
> a paragraph
> >with
> >     a matching beginning. Boilerplate error?
> >
> >     (The document does seem to have the reference to RFC 
> 2119 which the
> >     ID-Checklist requires).
> >
> >  Checking references for intended status: Experimental
> > 
> >-------------------------------------------------------------
> -----------
> >----
> >
> >idnits 2.11.12 found a few things (I've deleted a couple of
> >obviously incorrect "Missing Reference:" warnings):
> >
> >  Checking nits according to 
> http://www.ietf.org/ID-Checklist.html:  == Unused Reference: 
> 'RFC2045' is defined on line 475, but no explicit
> >     reference was found in the text
> >  
> >
> Not sure if this one is needed or not.
> 
> >  == Unused Reference: 'RFC2183' is defined on line 486, but 
> no explicit
> >     reference was found in the text
> >  
> >
> I've entered an RFC Editor note that updates the document to 
> reference 
> this RFC.
> 
> >  ** Obsolete normative reference: RFC 1341 (Obsoleted by RFC 1521)  
> >
> According to authors this reference is intentional.
> 
> 
>