Abstract
The standards for Internationalized Domain Names in Applications
(IDNA) require a review of each new version of Unicode to determine
whether incompatibilities with prior version or other issues exist
and, where appropriate, to allow the IETF to decide on the trade-offs
between compatibility with prior IDNA versions and compatibility with
Unicode going forward. That requirement, and its relationship to
tables maintained by IANA, has caused significant confusion in the
past. This document makes adjustments to the review procedure based
on experience and updates IDNA, specifically RFC 5892, to reflect
those changes and clarify the various relationships involved. It
also makes other minor adjustments to align that document with
experience.
The main changes are described in Appendix A of the document:
At a very high level, this document clarifies that
two types of review were intended and separates them for clarity and
restores the original (but so far unobserved) default for actions
when code point derived properties change. For this reason, this
document effectively provides a replacement for Section 5.1 of RFC
5892 and adds or changes some material needed to have the replacement
be clear or make better sense.
Changes or clarifications that may be considered important include:
o Separated the new Unicode version review into two explicit parts
and provided for different review methods and, potentially,
asynchronous outcomes.
o Specified a review team, not a single expert, for the code point
review.
o Eliminated the de facto requirement for the (formerly single)
Designated Expert to be the same person as the IAB's Liaison to
the Unicode Consortium but called out the importance of
coordination.
o Created an explicit provision for an "under review" entry in the
IANA tables so that, if there is ever again a need to tell the
community to wait until the IETF sorts things out, that will be
about selected potentially problematic code points and not whole
Unicode versions.
o In part because Unicode is now on a regular one-year cycle rather
than producing major and minor versions as needed, to avoid
overloading the IETF's i18n resources, and to avoid generating and
storing IANA tables for trivial changes (e.g., the single new code
point in Unicode 12.1), the review procedure is applied only to
major versions of Unicode unless exceptional circumstances arise
and are identified.
While this document is primarily an update to review procedures, it is
an update to an existing standards track document, and therefore this
one is properly put forward as Proposed Standard.
2. Review and Consensus
This document has not been formally reviewed on any IETF list, including
on the i18ndir list, though a few key directorate participants have read
and commented on the document. It was mentioned on the iana-update list,
and some review comments came from there. That said, this is a document
regarding recommendations to the registry and registrar community that
could only be developed by experts on IDNA, of which the IETF has very
few. A 4-week IETF-wide Last Call (as required for individual
submissions) is more than enough time for the i18ndir list to remind
experts to take a final look and confirm that there is community
consensus, insofar as that ever exists for these kinds of documents.
The shepherd has done a review of the document and thinks it is
technically sound. The most controversial bit of this document is
actually section 4:
This document restores and clarifies that original language and
intent: absent extremely strong evidence on a per-code point basis
that preserving the validity status of possible existing (or
prohibited) labels would cause significant harm, Unicode changes that
would affect IDNA derived properties are to be reflected in IDNA
exceptions that preserves the status of those labels.
The shepherd is agnostic as to whether this is the correct move, but it
is the only pragmatic choice given the state of the world, and there was
no disagreement with that choice in any of the reviews.
3. Intellectual Property
Each author has stated that their direct, personal knowledge of any IPR
related to this document has already been disclosed, in conformance with
BCPs 78 and 79. There has been no other discussion of IPR regarding this
document, and the shepherd has no reason to believe that any applicable
IP exists.
4. Other Points
From the idnits check:
- The text describing the updates to 5892 in the Abstract seems
sufficient, so no change needed.
- The reference warnings are false positives. No downrefs
needed.