[apps-discuss] AppsDir review of draft-ietf-eai-rfc5721bis

["Murray S. Kucherawy" <[e-mail]>]

I have been selected as the Applications Area Directorate (appsdir) reviewer for this draft.  (For background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

[NOTE: This is an early review request received by AppsDir.  We typically review documents that are in IETF Last Call, so please ignore the boilerplate saying so.]

Please resolve these comments along with any other Last Call comments you may receive.  Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-eai-rfc5721bis-04
Title: POP3 Support for UTF-8
Reviewer: Murray S. Kucherawy
Review Date: April 22, 2012
IETF Last Call Date: n/a
IESG Telechat Date: n/a

Summary:
LANG fr
Ce document est presque pret a etre publie en tant qu'un RFC, mais il a quelques questions qui devraient etre resolues avant de la publication.
LANG en

Major Issues:

None.

Minor Issues:

1) Section 2: When LANG is issued with no parameters, thus requesting a list of supported languages, is that list expected to be ordered in any way?
It doesn't really matter, but the document should probably say one way or the other.  If a list order is specified by one of the referenced RFCs, I missed it.

2) Section 3.1: "The UTF8 command MAY fail."  This seems to be dangling. Can you say why, even if it's "for any operational reason" or something that
just sounds less random?

3) It seems to me the second and fifth paragraphs of Section 3.1 could be merged, though that might make the fifth one even larger than it is.  It's
possible the second could simply be dropped in favour of the fifth as the former seems to be a subset of the latter.  The authors might also want to
consider splitting the fifth one someplace, perhaps where it starts talking about sizes.

4) Section 5 refers to the "UTF-8" Response Code, when it's actually "UTF8".  This is a bit confusing.

5) Section 3.2: The USER argument to the UTF8 capability tells the client something about the USER, PASS and APOP commands.  As all of those are
basically authentication/credential commands, perhaps something less specific like "LOGIN", "AUTH" or "CRED" would be more appropriate?  Otherwise it looks more like it only applies to the USER command.

6) This document uses RFC2119 language.  In the Introduction, it says "email messages may be transmitted".  Suggest s/may/might/ or s/may/could/.

7) Similarly, there's a lot of use of non-caps "may" in Section 3.1.

8) Section 5, last paragraph: s/downconvert/down-convert/, and (alas) rather than talking about "mood", say something about having the resources to down-convert where it didn't before or something like that.

Nits:

1) The end of the second paragraph of the introduction is a long sentence that contains a list of what this document accomplishes.  I suggest turning
it into a bulleted list rather than "This document does A, and B, and C, and D, and ..."

2) There's frequent reference to "UTF-8 headers" where, in at least some cases, "UTF-8 header fields" is probably more accurate.

3) There's inconsistent use of reference name styles when referring to other drafts, e.g. [popimap-downgrade] vs. [I-D.ietf-eai-simpledowngrade].  Suggest converting the former to look like the latter.

4) Section 3.1: "Note that even in UTF-8 mode, MIME binary content-transfer-encoding is still not permitted."  Can a reference be added to where that's stipulated?

5) Section 6: "The section 2 and 3" and "The section 5" need to be changed to just "Sections 2 and 3" and "Section 5", respectively.

6) Section 7: I'm not a fan of normative language in Security Considerations. Normative stuff belongs in earlier sections.  I suggest changing the MUST
in the second paragraph to "are strongly advised to".

7) Section 7: "integrity-protect" should be "protect the integrity of", and there should be a comma after "[RFC2595]".

8) Section 3.1: "high guesses are better than small ones"; "small" should probably be "low".

-MSK