IDNA2008 and Unicode 11.0.0
draft-faltstrom-unicode11-08
Discuss
Yes
No Objection
No Record
Summary: Needs 9 more YES or NO OBJECTION positions to pass.
Warren Kumari Yes
Alvaro Retana No Record
Andrew Alston No Record
Erik Kline No Record
Francesca Palombini No Record
John Scudder No Record
Lars Eggert No Record
Martin Duke No Record
Murray Kucherawy No Record
Paul Wouters No Record
Robert Wilton No Record
Roman Danyliw No Record
Zaheduzzaman Sarker No Record
Éric Vyncke No Record
(Alexey Melnikov; former steering group member) (was Yes) Discuss
Based on recent discussions on I18NDir mailing list, I suggest that this document is being replaced (in place, to keep history) by <https://datatracker.ietf.org/doc/draft-faltstrom-unicode12/>. This would require another IETF LC.
(Adam Roach; former steering group member) Yes
Thanks to everyone for the impressive amount of work that has gone into creating this document. I have only a small number of editorial suggestions to make. --------------------------------------------------------------------------- I-D Nits reports: == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. == Unused Reference: 'I-D.freytag-troublesome-characters' is defined on line 527, but no explicit reference was found in the text == Unused Reference: 'N4330' is defined on line 546, but no explicit reference was found in the text --------------------------------------------------------------------------- Abstract: > Although IDNA2008 allows adding > exceptions to the algorithm for backward compatibility; however, this > document does not add any such exceptions. Grammar nit: either remove "Although" or remove the semicolon and the word "however." --------------------------------------------------------------------------- §1: > There was three incompatible changes in the Unicode standard after Nit: "There were..." > derived property value from PVALID to DISSALOWED. They where > examined in great detail and IETF concluded that the consensus is Nit: "They were..." > there are changes in the derived property value is a result of the Nit: "...as a result..." --------------------------------------------------------------------------- §5: > As including an exception would require implementation > changes in deployed implementations of IDNA20008, the editor proposes > that such a BackwardCompatible rule NOT to be added to IDNA2008. This seems like the kind of thing we'd see in a draft as opposed to a published RFC. Perhaps rephrase as "...the IETF has concluded that such a BackwardCompatible rule will NOT be added to IDNS2008."
(Alissa Cooper; former steering group member) Yes
Thanks to all of those who have been working on this document. I added a management item to approve the tables on March 14, so the ballot text below from the week of the March 7 telechat is no longer relevant. Keeping it here for reference: Nearly a year ago, the IAB issued a statement encouraging the IETF community to bring the IDNA tables into alignment with the then-current version of Unicode <https://www.iab.org/documents/correspondence-reports-documents/2018-2/iab-statement-on-identifiers-and-unicode/>. Given how much time has passed, we are not quite able to achieve this goal. Unicode 12 is expected to be published on March 5 and this document brings the tables into alignment with Unicode 11. Nevertheless, to avoid further delays, I'd like to suggest that if the IESG is unable to approve this document on the March 7 telechat because of issues arising during IESG evaluation that would not affect the contents of the tables themselves, that we immediately add a management item to the telechat agenda that day to approve a direct request for IANA to update the IDNA Parameters registry of derived property values to align with what is described in this document, after the expert reviewer validates that the derived property values are calculated correctly.
(Benjamin Kaduk; former steering group member) No Objection
I just have some editorial comments/suggestions; I'll try to trim the
ones already noted by other ADs (especially the "editor proposes" line
that Adam noted, which I agree with).
Abstract
Although IDNA2008 allows adding
exceptions to the algorithm for backward compatibility; however, this
document does not add any such exceptions. This document provides
the necessary tables to IANA to make its database consisstent with
nit: "consistent"
Section 1
o Assigning code points can create problems if the newly-assigned
code points are compositions of existing code points and because
of that the normalization relationships associated with those code
points should have been changed.
nit: I'm having a hard time parsing this, that a new code point can
literally be the composition of existing code points; does not the mere
existence of different codepoints make them distinct? (On the other
hand, it's not clear to me that it's correct to just say "equivalent
to", since that does not specify what metric to use for the comparison.)
Section 3.1
o The Unicode Code Points and Internationalized Domain Names for
Applications (IDNA) [RFC5892], informally called "Tables", lists
the categories and rules that identify the code points allowed in
a label written in native character form (called a "U-label"), and
is based on Unicode 5.2.0 [Unicode-5.2.0] code point assignments
and additional rules unique to IDNA2008. The Unicode-based rules
in RFC 4892 are expected to be stable across Unicode updates and
hence independent of Unicode versions. RFC 5892 [RFC5892]
s/4892/5892/
Section 3.2
There are other documents important for the understanding and
functioning of IDNA2008, for example this.
I can't tell if "this" is supposed to be [draft-faltstrom-unicode11] or
"the following"; if the latter, I'd suggest just "for example:".
Section 3.3
In practice, the Unicode Consortium creates a maximum set of code
points by assigning code points in the Unicode Standard. The
"maximum set" in what scope/for what use case?
IDNA2008 rules use the Unicode Standard to create a further subset of
code points and context that are permitted in DNS labels associated
with its PVALID, CONTEXTJ, and CONTEXTO derived property values. [...]
nit: is this supposed to be "further subset of code points that are
permitted in DNS labels as well as further context-specific
restrictions"?
Appendices
It might be good to state in the preface the motivation for including
the changes from UNASSIGNED to PVALID/DISALLOWED at intermediate
versions (I assume to have a fixed record of the derived property
without reproducing the full table at each intermediate version),
especially when the actual symbol descriptions are not always visible,
since there are a lot of ranges and the right half of the range gets
truncated.
(Deborah Brungard; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
(Spencer Dawkins; former steering group member) (was Discuss) No Objection