I am the assigned Internationalization Directorate (i18ndir) reviewer for this draft.
Harald Alvestrand and Pete Resnik contributed to this review.

The Internationalization Directorate has been formed only recently,
and has not yet established a review template or an FAQ.
The review is intended to concentrate on internationalization issues,
but is not limited to such issues.

Please treat these comments just like any other last call comments.



General:
=======

It's good that this document is being done, EAI can only work better if 
it's clear where in the infrastructure U-labels are to be used, and 
where A-labels, and what happens with non-ASCII LHS.

It's a pity that there are not more places where U-labels are used, but 
that may be difficult to change.



Major/intermediate issues:
=========================

The Abstract mentions the Authentication-Results header field, but the 
text doesn't.

Section 4, %{s} and %{l} macros in SPF: The draft says that these cannot 
be used for local parts that contain non-ASCII characters. This may be 
enough for this draft, but is this a problem that should be fixed in the 
longer term? How widely are %{s} and %{l} macros used currently?

Section 5, grammar of dkim-safe-char: This adds all of Unicode 
(therewith not including overlong encodings or surrogates), which is 
probably the best thing that can be done in the grammar; any try to eliminate e.g. 
non-characters, characters with control functions, invisible characters, 
unassigned code points, private-use code points, and the like would be 
very difficult. But there should be a warning about this in the security 
section.

It may be appropriate to give a warning to implementers that they have 
to make sure that for internationalized messages, the DKIM signatures 
are calculated on UTF-8 strings. My assumption is that this should just 
work with the usual signature algorithms and the usual APIs, but some 
implementations may use special checks or so that would cause problems.



Minor issues:
============

In Abstract, fix "Authentication-Results header" -> 
"Authentication-Results header field"


1. Introduction:

This should start with a short section listing the documents/definitions 
that the reader is supposed to be familiar with.

"unencoded message bodies": Does this mean message bodies in ASCII only? 
I'm not sure this needs special mention; A-labels would also be needed 
e.g. for Korean domains in a message body encoded as Shift_JIS.

"Internationalized mail also allows UTF-8 characters": There are no 
UTF-8 characters. There are ((non-ASCII) Unicode) characters encoded 
as/in UTF-8. Please fix. (several places)


2. Definitions:

    The term IDN, for Internationalized Domain Name, refers to a domain
    name containing either U-labels or A-labels.
What about domain names with mixed U-labels and A-labels?

The draft says:
   Since DMARC is not currently a standards track protocol, this
   specification offers advice rather than requirements for DMARC.
but then the abstract says
   This specification updates the SPF, DKIM, and DMARC
   specifications
and the DMARC section (section 6) looks as if it's just as normative as
the others.
Either way may be fine (allowing informationals
to be updated is not a bad idea), but it should be self-consistent.

Section 5 repeatedly uses the term "internationalized messages", but it 
doesn't seem to be defined. The intent seems to be to refer to messages 
with RFC 6532 headers (which are called "internationalized email 
headers" in RFC 6532; it uses the term "internationalized messages" only 
in the context of message/global).

In section 5, please consider referencing RFC 5982.

6. DMARC ...

This would be easier to read, in particular for outsiders, if special 
terms such as "RFC5322.From", "rua", and "ruf" were quoted.



Nits:
====

Please fix capitalization of headers (e.g. General principles -> General 
Principles).

"This rule is
    relaxed only for headers in internationalized messages [RFC6532] so
    IDNs SHOULD be represented as U-labels but MAY be A-labels."
is a bit difficult to read. I'd propose a rewrite along the following lines:
"This rule is
    relaxed only for headers in internationalized messages [RFC6532].
    In such headers, IDNs SHOULD be represented as U-labels but MAY
    be represented as A-labels."

"Field names are restricted to printable ASCII (see
    [RFC5322] section 3.6.8) so this case conversion remains the usual
    ASCII conversion."
->
"Field names are restricted to printable ASCII (see
    [RFC5322] section 3.6.8) so this case conversion remains limited to
    ASCII characters."
(We don't want to give the impression that non-ASCII characters are unusual; they are not.)

"Since a policy record can
    be used for both internationalized and conventional mail, those
    addresses still have to be conventional addresses, not
    internationalized addresses."
->
"Since a policy record can
    be used for both internationalized and conventional mail, those
    addresses still have to be ASCII-only addresses, not
    internationalized addresses."
(We don't want to give the impression that addresses with non-ASCII characters are non-conventional.)