Last Call Review of draft-ietf-eai-5738bis-
review-ietf-eai-5738bis-genart-lc-campbell-2012-09-20-00

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> .

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-ietf-eai-5738bis-09
Reviewer: Ben Campbell
Review Date: 2012-09-18
IETF LC End Date: 2012-09-20

Summary: The draft is almost ready for publication as a proposed standard. I
have a few editorial comments as well as some questions about how this relates
to the EAI downgrade drafts.

Major issues: None

Minor issues:

-- section 7 talks about how to handle MUAs that do not understand the UTF8
extensions. It talks about doing complex vs rudimentary downgrades, and lists
draft-ietf-eai-popimap-downgrade and draft-ietf-eai-simpledowngrade as
examples. These are both informational references. I note, however, that both
of those drafts are standards track, which makes me wonder if the authors
expected a normative reference?

Along the same lines, section 7 seems to go to lengths to illustrate why
downgrading is somewhere between hard and  problematic. Do we really believe
that downgrading will ever be the "least bad"?

Nits/editorial comments:

-- IDNits reports issues; please check.

-- Abstract: "This specification replaces RFC 5738."

s/replaces/obsoletes
 (repeats in the last paragraph of section 1).

-- section 3, 1st paragraph: "Note that the "UTF8=ONLY" capability described in
Section 6 implies the "UTF8=ACCEPT" capability."

I assumed from  context (the paragraph talks about client's use of ENABLE) that
 this refers to client use of the ENABLE command. But section 6 talks about
server usemof the capability.

-- 3, 2nd to last paragraph: "Mailbox names MUST comply with the Net-Unicode
Definition (Section 2 of [RFC5198]) with the specific exception that they MUST
NOT contain control characters (0000-001F, 0080-009F), delete (007F), line
separator (2028), or paragraph separator (2029)."

You might consider recasting that in terms of actor behavior (i.e. what must a
client and/or server do), given that the mailbox name doesn't get much say in
the matter. This would be more consistent with the adjoining normative text
(e.g. the next paragraph talks about how a client MUST do something and a
server SHOULD enforce it.)

-- 4, 2nd to last paragraph:

Can this sentence be broken up or otherwise simplified? I found it easy to get
lost in the conditions.

-- 6, 1st paragraph: "As this is an incompatible change to IMAP, a clear
warning is necessary.  IMAP clients that find implementation of the "UTF8=ONLY"
capability problematic are encouraged to at least detect the "UTF8=ONLY"
capability and provide an informative error message to the end-user."

Seems like this should warrant a SHOULD

-- 6, 2nd paragraph: 'The "UTF8=ONLY" capability includes all of the functions
of "UTF8=ACCEPT"'

Previous text said UTF8-ONLY implied UTF8-ACCEPT. That's subtly different than
the language in this section. There may not be a practical difference, but it
would be better to be consistent.

-- 7, 3rd paragraph: "... not really "downgraded ones" (although that
terminology is often used for convenience) ..."

is there a formal definition of downgrade somewhere? Otherwise it's not clear
what the objection to its use is.

-- section 9, 1st paragraph:

Is OBSOLETE in all-caps on purpose? It's not a 2119 term.