Last Call Review of draft-ietf-dmarc-eaiauth-03
review-ietf-dmarc-eaiauth-03-i18ndir-lc-duerst-2019-03-14-00

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.)