Ballot for draft-faltstrom-unicode11
Discuss
Yes
No Objection
No Record
Summary: Needs 9 more YES or NO OBJECTION positions to pass.
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.
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."
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.
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.