Internationalized Domain Names for Applications 2008 (IDNA2008) and Unicode 12.0.0
draft-faltstrom-unicode12-07
Yes
Francesca Palombini
Murray Kucherawy
No Objection
Erik Kline
Zaheduzzaman Sarker
(Alvaro Retana)
(Robert Wilton)
Note: This ballot was opened for revision 06 and is now closed.
Francesca Palombini
Yes
Murray Kucherawy
Yes
Erik Kline
No Objection
Roman Danyliw
No Objection
Comment
(2022-02-02 for -06)
Sent
Thanks to Sam Weiler for the SECDIR review. ** Section 1. Editorial. OLD The summary below is a summary to make the reading of this document easier. NEW Below is a summary to aid in the reading of this document ** Section 1. Typo. s/exampined/examined/ ** Section 1. Editorial. s/ a number of PVALID code points of long Standing/a number of long standing PVALID code points/
Zaheduzzaman Sarker
No Objection
Éric Vyncke
No Objection
Comment
(2022-02-01 for -06)
Sent
Important document, easy to read, and fascinating by some aspects but way above my area of expertise: trusting ART ADs and the I18N directorate on this one. One minor cosmetic regret: not having the characters displayed in the table as UTF-8 can be included in the I-D.
Benjamin Kaduk Former IESG member
Yes
Yes
(2022-02-01 for -06)
Sent
I previously reviewed draft-faltstrom-unicode11-08, and accordingly have little new to add to this document. That said, I did look at the diff between the two drafts, and was surprised to see that in the appendices depicting the changes between Unicode version N and version N+1, which claim to be covering the same blocks of changes in the two I-Ds, are not the same! I have a shadow of a memory of Patrick having found errors in these tables back at that time, but would appreciate confirmation that the draft-faltstrom-unicode11-08 versions are/were in error and the draft-faltstrom-unicode12-06 versions are believed to be correct (ideally, having received review from multiple parties). Section 2.1 o Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale [RFC5894], informally called "Rationale", provides an overview of the protocol and associated tables, and gives explanatory material and some rationale for the decisions that led to IDNA2008. It also contains advice for DNS registry operators and others who use Internationalized Domain Names (IDNs). o Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008 [RFC5895], informally called "Mapping", discusses the issue of mapping characters into other characters and provides guidance for doing so when that is appropriate. RFC 5895 provides advice only and is not a required part of IDNA. RFCs 5894 and 5895 are both listed as informative references, but only the paragraph about 5895 has the "provides advice only and is not a required part" disclaimer. Would the disclaimer apply to 5894 as well? NITS Section 4 5892 [RFC5892] section 2.7. If the code point is accepted, it might still be rejected if validated by software based on older versions of Unicode than 11.0.0. As the character is rarely used outside of the s/11/12/ (since the start of the section talks about changes between 6.0.0 and 12.0.0 like the rest of the document). Section 9.2 I hope the RFC Editor will be able to sort the [UnicodeN] references in numeric (rather than string) order.
Alvaro Retana Former IESG member
No Objection
No Objection
(for -06)
Not sent
Lars Eggert Former IESG member
No Objection
No Objection
(2022-02-03 for -06)
Sent
This document uses the RFC2119 keyword "REQUIRED", but does not contain the recommended RFC8174 boilerplate. Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Terms "man" and "woman"; alternatives might be "individual", "people", "person". * Term "native"; alternatives might be "built-in", "fundamental", "ingrained", "intrinsic", "original". Thanks to Russ Housley for their General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/zFe26o6-S57-YLXaHyMdrkzQGnE). ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Document still refers to the "Simplified BSD License", which was corrected in the TLP on September 21, 2021. It should instead refer to the "Revised BSD License". Section 1. , paragraph 14, nit: > number of PVALID code points of long standing may have similar issues. While > ^^^^^^^^^^^^^ This word is normally spelled with a hyphen. Section 2.3. , paragraph 3, nit: > different profiles, there are several different variations that leave users w > ^^^^^^^^^^^^^^^^^ Consider using "several". Section 3.1. , paragraph 10, nit: > quences is not understood fully. Therefore it cannot be claimed that this ca > ^^^^^^^^^ A comma may be missing after the conjunctive/linking adverb "Therefore". Section 3.3. , paragraph 17, nit: > As the character is rarely used outside of the group of Sharada specialists, > ^^^^^^^^^^ This phrase is redundant. Consider using "outside". Reference [RFC3491] to RFC3491, which was obsoleted by RFC5891 (this may be on purpose). Reference [RFC3490] to RFC3490, which was obsoleted by RFC5890 and RFC5891 (this may be on purpose). Reference [RFC3454] to RFC3454, which was obsoleted by RFC7564 (this may be on purpose). These URLs in the document can probably be converted to HTTPS: * http://www.iana.org/assignments/idna-tables/ * http://www.unicode.org/reports/tr46/
Robert Wilton Former IESG member
No Objection
No Objection
(for -06)
Not sent