[dmarc-ietf] I18ndir last call review of draft-ietf-dmarc-eaiauth-03
Martin Dürst via Datatracker <noreply@ietf.org> Thu, 14 March 2019 09:55 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: dmarc@ietf.org
Delivered-To: dmarc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE497129441; Thu, 14 Mar 2019 02:55:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Martin Dürst via Datatracker <noreply@ietf.org>
To: i18ndir@ietf.org
Cc: dmarc@ietf.org, draft-ietf-dmarc-eaiauth.all@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.94.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Martin Dürst <duerst@it.aoyama.ac.jp>
Message-ID: <155255732161.2699.16055637076396529424@ietfa.amsl.com>
Date: Thu, 14 Mar 2019 02:55:21 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/c1EXET5n5BoJx17Y5kIIjI9YiXw>
Subject: [dmarc-ietf] I18ndir last call review of draft-ietf-dmarc-eaiauth-03
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2019 09:55:22 -0000
Reviewer: Martin Dürst Review result: Ready with Issues 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.)
- [dmarc-ietf] I18ndir last call review of draft-ie… Martin Dürst via Datatracker
- Re: [dmarc-ietf] I18ndir last call review of draf… Kurt Andersen