Subject: [Gen-art] Gen-ART LC Review of draft-ietf-eai-5738bis-09

From: Ben Campbell <[email-masked]>
Date: Tue, 18 Sep 2012 20:44:15 -0500

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.

---

From: John C Klensin <[email-masked]>
Date: Wed, 19 Sep 2012 07:53:54 -0400

Following up on my earlier note about a comment from you that
really applies to the strategy on which all four documents are
really based...

--On Tuesday, September 18, 2012 20:44 -0500 Ben Campbell
<[email-masked]> wrote:

>...
> 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"?

As compared to what, Ben?  

One alternative is to not support delivery of SMTPUTF8 messages
at all except in environments in which it can be guaranteed that
all IMAP and POP clients that might contact the servers are
already upgraded.  It is operationally possible to make that
guarantee in a few scenarios, but they are rare.   In those
scenarios, many people in the WG would say "do that" (easily
managed by not having the delivery servers accept SMTPUTF8
messages until the POP/IMAP client upgrades are complete).
But, for all of the more usual cases in which the IMAP/POP
server operator cannot control exactly what clients might be
used, the only alternate is to not allow such messages, ever.
We don't think that is a desirable choice (or we wouldn't have
done the work in the WG) but nothing in these protocols require
that anyone deploy i18n mail.

For the other alternatives, yes, downgrading --by one of these
scenarios or some other one-- is, indeed, likely to be "less
bad" than others in some operational scenarios.   In particular,
one alternate is for the server to silently delete all messages
requiring SMTPUTF8 (EAI) capability if a client connects that
doesn't support the needed capability.  If only because the user
might later come back with a more capable client (or a message
access mechanism that doesn't use a POP or IMAP client at all),
that messaging-deleting alternative is almost certainly the
worst option of all, making almost anything else "less bad".

And, again, yes the WG discussed these issues at length, perhaps
even ad nauseam.

    john

---

From: Ben Campbell <[email-masked]>
Date: Thu, 20 Sep 2012 14:44:00 -0500

> As compared to what, Ben?  

(I assume that to be rhetorical :-) )

> And, again, yes the WG discussed these issues at length, perhaps

I'm willing to accept that the work group decided this was the best that could be done. My concern is that the current situation (5721bis normatively [with a MUST] references 5738 bis, which informatively references the downgrade drafts (as examples), which are themselves standards track) seems internally inconsistent.