SMTP Extension for Internationalized Email
draft-ietf-eai-rfc5336bis-16

It would be nice to condense Section 7 into "Changes from RFC 5336" and
retain it in the document.

---

I could not parse the Note in Section 1 well enough to understand where
the keyword to replace "UTF8SMTPbis" will actually be defined. It is
possible that [RFC5336bis-SMTP] is the intended document, however, it
is not mentioned anywhere in this I-D.

A way to handle this might be to put in some real (i.e. not a note to
be removed) text that makes a normative reference. Such as:
   The keyword UTF8SMTPbis is defined in [RFC5336bis-SMTP].
You would also need to add a normative reference to [RFC5336bis-SMTP]
When the note is acted on, this text will become correct.

I am hoping that the Responsible AD understands this issue well enough
to explain it to the RFC Editor.

There are id nits...

It would be helpful to cite RFC 3629 in Section 1.1.

It is nice that Section 1.1 says "this specification replaces an earlier, experimental, approach to the same problem [RFC5336]." It would be even nicer to describe the results of the experiment and the resulting protocol differences (probably in an Appendix).

Section 3.2 states: "Any domain name to be looked up in the DNS MUST allow for [RFC5890] behavior." I don't understand what this means, and I find the use of the passive voice confusing here. Does this mean than an SMTP server advertising support for the UTF8SMTPbis extension MUST accept DNS domain names that conform to RFC 5890? If so, let's say that directly.

Section 3.2 states: "it may choose its own way to deal with this scenario according to the provisions of [RFC4409] or its future versions." Do we mean "MAY"?

Section 3.5 states: "A UTF8SMTPbis-aware SMTP client MUST only send an internationalized message to an SMTP server that supports UTF8SMTPbis." I think it would be clearer to say "A UTF8SMTPbis-aware SMTP client MUST NOT send an internationalized message to an SMTP server that does not support UTF8SMTPbis."

Section 5 states: "Another security aspect to be considered is related to the ability by security team members to quickly understand, read and identify email addresses from the logs, when they are tracking an incident." Because reading and understanding an email address would require the person to be capable of reading the script and understanding the language, I think "identify" is all we can hope to promise here (and even that is unlikely in some situations given the existence of confusable characters).

When the changes section gets removed, the hint of what happened to the appendix in 5336 that updated 4952 goes with it. Would it be easy to add a short note somewhere letting the reader know to go look for that in 4952bis?

  Please consider this editorial comment from the Gen-ART Review by
  Pete McCann on 17-Oct-2011:

  Section 3.6:
    The message being sent via the MAIL command with the UTF8SMTPbis
    parameter has still a chance of that the message transmitted is not
    an internationalized message.
  SHOULD BE:
    There is still a chance that a message being sent via the MAIL
    command with the UTF8SMTPbis parameter is not an internationalized
    message.

#1) Do the authors also wish to make RFC 5336 Historic?

#2) Please add a section that lists the difference between RFC 5336 and this document.