IDNA2008 and Unicode 11.0.0
draft-faltstrom-unicode11-08
Discuss
Yes
Warren Kumari
No Objection
(Deborah Brungard)
(Mirja Kühlewind)
(Spencer Dawkins)
No Record
Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Zaheduzzaman Sarker
Éric Vyncke
Summary: Needs 9 more YES or NO OBJECTION positions to pass.
Warren Kumari
Yes
Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
No Record
Alexey Melnikov Former IESG member
(was Yes)
Discuss
Discuss
[Treat as non-blocking comment]
(2019-03-13)
Not sent
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 IESG member
Yes
Yes
(2019-03-12)
Sent
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 IESG member
Yes
Yes
(2019-03-11)
Sent
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 IESG member
No Objection
No Objection
(2019-03-12)
Not sent
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 IESG member
No Objection
No Objection
(for -07)
Not sent
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -07)
Not sent
Spencer Dawkins Former IESG member
(was Discuss)
No Objection
No Objection
()
Sent for earlier