Skip to main content

Shepherd writeup


    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

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

    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

    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