SMTP Extension for Internationalized Email
RFC 6531

Note: This ballot was opened for revision 16 and is now closed.

(Pete Resnick) Yes

Comment (2011-10-13 for -)
No email
send info
Editorial comment that should be taken care of with the rest of Last Call comments: In 3.2 and 3.6, references to 2045 and 2047 are sometimes just poorly worded and sometimes incorrect. For example, in 3.2:

   If the UTF8SMTPbis SMTP extension is not offered by the SMTP server,
   the UTF8SMTPbis-aware SMTP client MUST NOT transmit an
   internationalized email address and MUST NOT transmit a mail message
   containing internationalized mail headers as described in
   [RFC5335bis] at any level within its MIME structure [RFC2045] and
   [RFC2047].

The last bit should simply be "within its MIME [RFC2045] structure". There should be no reference to 2047 here. See also section 3.6.

(Jari Arkko) No Objection

Comment (2011-10-20 for -)
No email
send info
There are id nits...

(Ron Bonica) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2011-10-18 for -)
No email
send info
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.

(Stephen Farrell) No Objection

(David Harrington) No Objection

(Russ Housley) No Objection

Comment (2011-10-20 for -)
No email
send info
  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.

(Peter Saint-Andre) No Objection

Comment (2011-10-19 for -)
No email
send info
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).

(Robert Sparks) (was Discuss) No Objection

Comment (2011-10-18)
No email
send info
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?

(Sean Turner) (was Discuss) No Objection

Comment (2011-10-16)
No email
send info
#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.