[Gen-art] Gen-ART review of draft-ietf-eai-imap-utf8-07 - Status
<Black_David@emc.com> Wed, 09 September 2009 13:18 UTC
Return-Path: <Black_David@emc.com>
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A92093A6AED for <gen-art@core3.amsl.com>; Wed, 9 Sep 2009 06:18:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tqx3k3wwXyIT for <gen-art@core3.amsl.com>; Wed, 9 Sep 2009 06:18:05 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 0E2FF3A67C1 for <gen-art@ietf.org>; Wed, 9 Sep 2009 06:18:04 -0700 (PDT)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id n89DIaSE003575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Sep 2009 09:18:36 -0400
Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Wed, 9 Sep 2009 09:18:23 -0400
Received: from corpussmtp2.corp.emc.com (corpussmtp2.corp.emc.com [128.221.166.45]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n89DINSI029264; Wed, 9 Sep 2009 09:18:23 -0400
Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp2.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 09:18:22 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 09 Sep 2009 09:18:22 -0400
Message-ID: <9FA859626025B64FBC2AF149D97C944A03BB22EA@CORPUSMX80A.corp.emc.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Gen-ART review of draft-ietf-eai-imap-utf8-07 - Status
Thread-Index: AcoqCS1wGUETxGUMRJ2ENjm0Y0hn+wHRbecg
From: Black_David@emc.com
To: housley@vigilsec.com
X-OriginalArrivalTime: 09 Sep 2009 13:18:22.0938 (UTC) FILETIME=[01B6C3A0:01CA3150]
X-EMM-EM: Active
Cc: alexey.melnikov@isode.com, gen-art@ietf.org, Black_David@emc.com
Subject: [Gen-art] Gen-ART review of draft-ietf-eai-imap-utf8-07 - Status
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Sep 2009 13:18:06 -0000
Russ, Status on this review - the draft is ok with the current RFC Editor notes in the ballot, but a couple more RFC Editor notes would be desirable. First, the two open issues have been resolved: > - The header upconversion behavior specification for non-UTF-8 > mailstores appears to be incomplete. The rest of the specification turns out to be in RFC 3501 (base IMAP spec) if one knows where to look (Alexey knew where to look). The modifications to IMAP in this draft cannot be reasonably implemented without carefully consulting RFC 3501, so that should be fine. > - The recommendation to support MIME header upconversion for > "Other widely deployed MIME charsets" strikes me as > too vague to be useful guidance to implementers. One of the RFC Editor notes replaces this recommendation with much better language that actually provides useful guidance. The following two editorial items are candidates for RFC Editor notes: (1) 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). (2) 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. There's a good chance that the authors have a -08 version that contains these editorial changes. Thanks, --David -----Original Message----- From: Black, David Sent: Monday, August 31, 2009 3:04 AM To: presnick@qualcomm.com; chris.newman@sun.com; 'Gen Art'; Harald Alvestrand Cc: Black, David; Alexey Melnikov; XiaoDong Lee; ima@ietf.org Subject: Gen-ART review of draft-ietf-eai-imap-utf8-07 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. 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. 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). 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. This would normally be covered by a shepherd's report, but I did not see one. 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? 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). 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: ------------------------------------------------------------------------ ---- ** 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 ------------------------------------------------------------------------ ---- == Unused Reference: 'RFC2045' is defined on line 475, but no explicit reference was found in the text == Unused Reference: 'RFC2183' is defined on line 486, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1341 (Obsoleted by RFC 1521) Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ----------------------------------------------------
- [Gen-art] Gen-ART review of draft-ietf-eai-imap-u… Black_David
- Re: [Gen-art] Gen-ART review of draft-ietf-eai-im… Alexey Melnikov