Summary:
This draft is on the right track, but has open issues, described in the review.

This draft describes a framework for international character support in 
mailbox names.  That easy-to-state requirement has a large scope of 
consequences, as it also requires:
	- international character support in message headers;
	- extensions to message delivery status and notification handling; and
	- i18n protocol extensions to SMTP, POP and IMAP.
Even so, the resulting email path coverage scope is not end-to-end, as 
important aspects of MUA behavior and interaction with users are 
out-of-scope (and I believe properly so).

The draft is well written, and does a good job of describing the overall 
framework of email transfer and the entities involved.  Unfortunately, that 
descriptive style carries over into the specification of the framework and 
interactions involved in international character support, and that 
descriptive (rather than prescriptive) style leads the open issues:

[1] The second sentence in the second paragraph of Section 7.2 begins with 
"That form SHOULD presumably use UTF-8".  I don't understand that, 
as "presumably" is not consistent with the RFC 2119 specification of 
"SHOULD".  The paragraph gets worse further on with a statement that 
something "can be done" to realize this "SHOULD presumably" requirement.  
I cannot figure out what this paragraph is specifying or recommending; 
it should be rewritten.  As part of the rewrite, please carefully separate 
functionality that is acceptable in transition from functionality that is part 
of the longer term "target" and say something about how to go about 
retiring the transition functionality from use.

[2] The last paragraph of Section 8.1 has a similar problem - "In this 
context, one can easily imagine modifications" is a fine introduction to 
a fairy tale, but does not belong in a framework RFC, even an Informational 
one.  Again, I cannot figure out what is being recommended here - on its 
face, the language is entirely hypothetical, but I suspect that there's 
something that should be said about when the techniques in this paragraph 
should be used and for what purposes.  Please rewrite.

[3] Section 10.1 seems problematic.  The open issue is that the draft declines 
to say anything definitive about how to deal with existing ("running code" 
use of the backspace character).  I suggest adding a discussion of making 
the backspace character an exception to the prohibition of Unicode C0 controls 
for transition purposes.

[4] Also in Section 10.1, the second bullet under the principles assumes that 
the mailbox name is normalized, as that was recommended by the first bullet.  
The other case should also be covered - if the mailbox name is not 
normalized, the draft should recommend that the normalized form of the mailbox 
name be an alias.  A non-obvious situation where this applies is to mailbox 
names that are not normalized wrt all applicable normalization forms, e.g., 
names that are in normal form with respect to NFC, but not with respect 
to NFKC.

The following item should also be dealt with, but does not rise to 
the level of an open issue:

[A] In Section 10.1, the warnings against unnormalized strings, use of spaces, 
punctuation, etc. seem weak, and would benefit from an example to make 
the point. Even though there's another draft referenced on MUA issues, 
the example I suggest involves a user sends a message to another user 
and expecting a reply.  In order for this example to work as intended, 
the first user's email address needs to survive the second user's MUA, 
which may normalize or fail to deal well with whitespace, punctuation, 
etc., independent of care taken in implementation of the first user's MUA.

-- Nits --

Please add citations of the i18n IMAP and POP specs to the last paragraph in Section 7.1.

idnits 2.12.05 found a lot to complain about, but only the following 
three items appear to deserve attention:

  == The 'Obsoletes: ' line in the draft header should list only the
     _numbers_ of the RFCs which will be obsoleted by this document (if
     approved); it should not include the word 'RFC' in the list.

  -- The document has a disclaimer for pre-RFC5378 work, but was first
     submitted on or after 10 November 2008.  Does it really need the
     disclaimer?

  == Unused Reference: 'RFC2033' is defined on line 1038, but no explicit
     reference was found in the text

I suspect that the disclaimer is needed courtesy of text taken from older 
documents, but that need should be double-checked.