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:[email protected]] > Sent: Tuesday, September 01, 2009 5:36 PM > To: Black, David > Cc: [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; [email protected] > Subject: Re: Gen-ART review of draft-ietf-eai-imap-utf8-07 > > Hi David, > Thank you for your detailed review. > > [email protected] 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. > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
