Internationalized Domain Names for Applications 2008 (IDNA2008) and Unicode 12.0.0
draft-faltstrom-unicode12-07

[Ballot comment]
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/

[Ballot comment]
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/

[Ballot comment]
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.

[Ballot comment]
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.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-faltstrom-unicode12-03.txt. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

Once the IDNA Parameters registry has the expert reviewer validate that the derived property values are calculated correctly, IANA will post the tables for 12.0.0 at https://www.iana.org/assignments/idna-tables.

IANA understands that it may not post anything later than the tables for 12.0.0.

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Michelle Cotton
IANA Services

The following Last Call announcement was sent out (ends 2021-11-16):

From: The IESG
To: IETF-Announce
CC: barryleiba@computer.org, draft-faltstrom-unicode12@ietf.org, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (IDNA2008 and Unicode 12.0.0) to Proposed Standard


The IESG has received a request from an individual submitter to consider the
following document: - 'IDNA2008 and Unicode 12.0.0'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-11-16. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes the changes between Unicode 6.2.0 and Unicode
  12.0.0 in the context of IDNA2008.  Some additions and changes have
  been made in the Unicode Standard that affect the values produced by
  the algorithm IDNA2008 specifies.  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
  Unicode 12.0.0.

  To improve understanding, this document describes systems that are
  being used as alternatives to those that conform to IDNA2008.

  TO BE REMOVED AT TIME OF PUBLICATION AS AN RFC:

  This document is discussed on the i18n-discuss@ietf.org mailing list
  of the IETF.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-faltstrom-unicode12/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc6912: Principles for Unicode Code Point Inclusion in Labels in the DNS (Informational - Internet Architecture Board (IAB))
    rfc5895: Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008 (Informational - Independent Submission)
    rfc5894: Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale (Informational - Internet Engineering Task Force (IETF))

1. Summary

This document describes the changes between Unicode 6.2.0 and Unicode
12.0.0 in the context of IDNA2008.  Some additions and changes have been
made in the Unicode Standard that affect the values produced by the
algorithm IDNA2008 specifies. This document provides the necessary tables
to IANA to make the IANA database consistent with Unicode 12.0.0.

This document adds to the IDNA2008 set of standards and, as with RFC
6452 that made similar analysis and revision for Unicode 6.0, is a
standards-track document.

Barry Leiba is the document shepherd, and Murray Kucherawy is the
responsible AD.


2. Review and Consensus

This document replaces draft-faltstrom-unicode11, which was intended to
take on the specified review and analysis for Unicode version 11, but
which did not get finished before Unicode version 12 was released and
before changes to the review process were documented in RFC 8753. There
was a good level of review of draft-faltstrom-unicode11, including
substantive review through the Internationalization Directorate (there
were also GenART and SecDir reviews), and those reviews serve this,
draft-faltstrom-unicode12, well.

It's important to keep in mind that the analysis that this document does
is highly specialized and that few IETF participants have the background
knowledge and skills to do that analysis.  As a result, we expect few
substantive reviews, and the consensus is necessarily achieved very
narrowly.  That said, the document and the analysis it provides is
critical to the stability of the IDNA2008 standards, to ensure that the
standard continues to align with current Unicode versions.

This document is a prerequisite for the review and analysis of Unicode
version 13.


3. Intellectual Property

This document is in full compliance with BCPs 78 and 79, and the author
is not aware of any intellectual property issues or claims related to
it.


4. Other Points

This document provides, in Appendix A, a table for IANA to use to update
their IDNA character database.  IANA is familiar with this process and
is well aware of what needs to be done.

There are some intentional references to obsolete RFCs, there for useful
background.