Internationalized Domain Names for Applications (IDNA) Review for New Unicode Versions
RFC 8753



Internet Engineering Task Force (IETF)                        J. Klensin
Request for Comments: 8753                                              
Updates: 5892                                               P. Fältström
Category: Standards Track                                         Netnod
ISSN: 2070-1721                                               April 2020

 Internationalized Domain Names for Applications (IDNA) Review for New
                            Unicode Versions

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 versions 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 to clarify the various relationships involved.  It
   also makes other minor adjustments to align that document with
   experience.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8753.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction
   2.  Brief History of IDNA Versions, the Review Requirement, and RFC
           5982
   3.  The Review Model
     3.1.  Review Model Part I: Algorithmic Comparison
     3.2.  Review Model Part II: New Code Point Analysis
   4.  IDNA Assumptions and Current Practice
   5.  Derived Tables Published by IANA
   6.  Editorial Clarification to RFC 5892
   7.  IANA Considerations
   8.  Security Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Appendix A.  Summary of Changes to RFC 5892
   Appendix B.  Background and Rationale for Expert Review Procedure
           for New Code Point Analysis
   Acknowledgments
   Authors' Addresses

1.  Introduction

   The standards for Internationalized Domain Names in Applications
   (IDNA) require a review of each new version of Unicode to determine
   whether incompatibilities with prior versions 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 [Unicode] going forward.  That requirement, and its
   relationship to tables maintained by IANA, has caused significant
   confusion in the past (see Section 3 and Section 4 for additional
   discussion of the question of appropriate decisions and the history
   of these reviews).  This document makes adjustments to the review
   procedure based on nearly a decade of experience and updates IDNA,
   specifically the document that specifies the relationship between
   Unicode code points and IDNA derived properties [RFC5892], to reflect
   those changes and to clarify the various relationships involved.

   This specification does not change the requirement that registries at
   all levels of the DNS tree take responsibility for the labels they
   insert in the DNS, a level of responsibility that requires allowing
   only a subset of the code points and strings allowed by the IDNA
   protocol itself.  That requirement is discussed in more detail in a
   companion document [RegRestr].

   Terminology note: In this document, "IDNA" refers to the current
   version as described in RFC 5890 [RFC5890] and subsequent documents
   and sometimes known as "IDNA2008".  Distinctions between it and the
   earlier version are explicit only where they are necessary for
   understanding the relationships involved, e.g., in Section 2.

2.  Brief History of IDNA Versions, the Review Requirement, and RFC 5982

   The original, now-obsolete, version of IDNA, commonly known as
   "IDNA2003" [RFC3490] [RFC3491], was defined in terms of a profile of
   a collection of IETF-specific tables [RFC3454] that specified the
   usability of each Unicode code point with IDNA.  Because the tables
   themselves were normative, they were intrinsically tied to a
   particular version of Unicode.  As Unicode evolved, the IDNA2003
   standard would have required the creation of a new profile for each
   new version of Unicode, or the tables would have fallen further and
   further behind.

   When IDNA2003 was superseded by the current version, known as
   IDNA2008 [RFC5890], a different strategy, one that was property-based
   rather than table-based, was adopted for a number of reasons, of
   which the reliance on normative tables was not dominant [RFC4690].
   In the IDNA2008 model, the use of normative tables was replaced by a
   set of procedures and rules that operated on Unicode properties
   [Unicode-properties] and a few internal definitions to determine the
   category and status, and hence an IDNA-specific "derived property",
   for any given code point.  Those rules are, in principle, independent
   of Unicode versions.  They can be applied to any version of Unicode,
   at least from approximately version 5.0 forward, to yield an
   appropriate set of derived properties.  However, the working group
   that defined IDNA2008 recognized that not all of the Unicode
   properties were completely stable and that, because the criteria for
   new code points and property assignment used by the Unicode
   Consortium might not precisely align with the needs of IDNA, there
   were possibilities of incompatible changes to the derived property
   values.  More specifically, there could be changes that would make
   previously disallowed labels valid, previously valid labels
   disallowed, or that would be disruptive to IDNA's defining rule
   structure.  Consequently, IDNA2008 provided for an expert review of
   each new version of Unicode with the possibility of providing
   exceptions to the rules for particular new code points, code points
   whose properties had changed, and newly discovered issues with the
   IDNA2008 collection of rules.  When problems were identified, the
   reviewer was expected to notify the IESG.  The assumption was that
   the IETF would review the situation and modify IDNA2008 as needed,
   most likely by adding exceptions to preserve backward compatibility
   (see Section 3.1).

   For the convenience of the community, IDNA2008 also provided that
   IANA would maintain copies of calculated tables resulting from each
   review, showing the derived properties for each code point.  Those
   tables were expected to be helpful, especially to those without the
   facilities to easily compute derived properties themselves.
   Experience with the community and those tables has shown that they
   have been confused with the normative tables of IDNA2003: the
   IDNA2008 tables published by IANA have never been normative, and
   statements about IDNA2008 being out of date with regard to some
   Unicode version because the IANA tables have not been updated are
   incorrect or meaningless.

3.  The Review Model

   While the text has sometimes been interpreted differently, IDNA2008
   actually calls for two types of review when a new Unicode version is
   introduced.  One is an algorithmic comparison of the set of derived
   properties calculated from the new version of Unicode to the derived
   properties calculated from the previous one to determine whether
   incompatible changes have occurred.  The other is a review of newly
   assigned code points to determine whether any of them require special
   treatment (e.g., assignment of what IDNA2008 calls contextual rules)
   and whether any of them violate any of the assumptions underlying the
   IDNA2008 derived property calculations.  Any of the cases of either
   review might require either per-code point exceptions or other
   adjustments to the rules for deriving properties that are part of RFC
   5892.  The subsections below provide a revised specification for the
   review procedure.

   Unless the IESG or the designated expert team concludes that there
   are special problems or unusual circumstances, these reviews will be
   performed only for major Unicode versions (those numbered NN.0, e.g.,
   12.0) and not for minor updates (e.g., 12.1).

   As can be seen in the detailed descriptions in the following
   subsections, proper review will require a team of experts that has
   both broad and specific skills in reviewing Unicode characters and
   their properties in relation to both the written standards and
   operational needs.  The IESG will need to appoint experts who can
   draw on the broader community to obtain the necessary skills for
   particular situations.  See the IANA Considerations (Section 7) for
   details.

3.1.  Review Model Part I: Algorithmic Comparison

   Section 5.1 of RFC 5892 is the description of the process for
   creating the initial IANA tables.  It is noteworthy that, while it
   can be read as strongly implying new reviews and new tables for
   versions of Unicode after 5.2, it does not explicitly specify those
   reviews or, e.g., the timetable for completing them.  It also
   indicates that incompatibilities are to be "flagged for the IESG" but
   does not specify exactly what the IESG is to do about them and when.
   For reasons related to the other type of review and discussed below,
   only one review was completed, documented [RFC6452], and a set of
   corresponding new tables installed.  That review, which was for
   Unicode 6.0, found only three incompatibilities; the consensus was to
   ignore them (not create exceptions in IDNA2008) and to remain
   consistent with computations based on current (Unicode 6.0)
   properties rather than preserving backward compatibility within IDNA.
   The 2018 review (for Unicode 11.0 and versions in between it and 6.0)
   [IDNA-Unicode12] also concluded that Unicode compatibility, rather
   than IDNA backward compatibility, should be maintained.  That
   decision was partially driven by the long period between reviews and
   the concern that table calculations by others in the interim could
   result in unexpected incompatibilities if derived property
   definitions were then changed.  See Section 4 for further discussion
   of these preferences.

3.2.  Review Model Part II: New Code Point Analysis

   The second type of review, which is not clearly explained in RFC
   5892, is intended to identify cases in which newly added or recently
   discovered problematic code points violate the design assumptions of
   IDNA, to identify defects in those assumptions, or to identify
   inconsistencies (from an IDNA perspective) with Unicode commitments
   about assignment, properties, and stability of newly added code
   points.  One example of this type of review was the discovery of new
   code points after Unicode 7.0 that were potentially visually
   equivalent, in the same script, to previously available code point
   sequences [IAB-Unicode7-2015] [IDNA-Unicode7].

   Because multiple perspectives on Unicode and writing systems are
   required, this review will not be successful unless it is done by a
   team.  Finding one all-knowing expert is improbable, and a single
   expert is unlikely to produce an adequate analysis.  Rather than any
   single expert being the sole source of analysis, the designated
   expert (DE) team needs to understand that there will always be gaps
   in their knowledge, to know what they don't know, and to work to find
   the expertise that each review requires.  It is also important that
   the DE team maintains close contact with the Area Directors (ADs) and
   that the ADs remain aware of the team's changing needs, examining and
   adjusting the team's membership over time, with periodic
   reexamination at least annually.  It should also be recognized that,
   if this review identifies a problem, that problem is likely to be
   complex and/or involve multiple trade-offs.  Actions to deal with it
   are likely to be disruptive (although perhaps not to large
   communities of users), or to leave security risks (opportunities for
   attacks and inadvertent confusion as expected matches do not occur),
   or to cause excessive reliance on registries understanding and taking
   responsibility for what they are registering [RFC5894] [RegRestr].
   The latter, while a requirement of IDNA, has often not worked out
   well in the past.

   Because resolution of problems identified by this part of the review
   may take some time even if that resolution is to add additional
   contextual rules or to disallow one or more code points, there will
   be cases in which it will be appropriate to publish the results of
   the algorithmic review and to provide IANA with corresponding tables,
   with warnings about code points whose status is uncertain until there
   is IETF consensus about how to proceed.  The affected code points
   should be considered unsafe and identified as "under review" in the
   IANA tables until final derived properties are assigned.

4.  IDNA Assumptions and Current Practice

   At the time the IDNA2008 documents were written, the assumption was
   that, if new versions of Unicode introduced incompatible changes, the
   Standard would be updated to preserve backward compatibility for
   users of IDNA.  For most purposes, this would be done by adding to
   the table of exceptions associated with Rule G [RFC5892a].

   This has not been the practice in the reviews completed subsequent to
   Unicode 5.2, as discussed in Section 3.  Incompatibilities were
   identified in Unicode 6.0 [RFC6452] and in the cumulative review
   leading to tables for Unicode 11.0 [IDNA-Unicode11].  In all of those
   cases, the decision was made to maintain compatibility with Unicode
   properties rather than with prior versions of IDNA.

   If an algorithmic review detects changes in Unicode after version
   12.0 that would break compatibility with derived properties
   associated with prior versions of Unicode or changes that would
   preserve compatibility within IDNA at the cost of departing from
   current Unicode specifications, those changes must be captured in
   documents expected to be published as Standards Track RFCs so that
   the IETF can review those changes and maintain a historical record.

   The community has now made decisions and updated tables for Unicode
   6.0 [RFC6452], done catch-up work between it and Unicode 11.0
   [IDNA-Unicode11], and completed the review and tables for Unicode
   12.0 [IDNA-Unicode12].  The decisions made in those cases were driven
   by preserving consistency with Unicode and Unicode property changes
   for reasons most clearly explained by the IAB [IAB-Unicode-2018].
   These actions were not only at variance with the language in RFC 5892
   but were also inconsistent with commitments to the registry and user
   communities to ensure that IDN labels that were once valid under
   IDNA2008 would remain valid, and previously invalid labels would
   remain invalid, except for those labels that were invalid because
   they contained unassigned code points.

   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 preserve the status of those labels.  There is one
   partial exception to this principle.  If the new code point analysis
   (see Section 3.2) concludes that some code points or collections of
   code points should be further analyzed, those code points, and labels
   including them, should be considered unsafe and used only with
   extreme caution because the conclusions of the analysis may change
   their derived property values and status.

5.  Derived Tables Published by IANA

   As discussed above, RFC 5892 specified that derived property tables
   be provided via an IANA registry.  Perhaps because most IANA
   registries are considered normative and authoritative, that registry
   has been the source of considerable confusion, including the
   incorrect assumption that the absence of published tables for
   versions of Unicode later than 6.0 meant that IDNA could not be used
   with later versions.  That position was raised in multiple ways, not
   all of them consistent, especially in the ICANN context
   [ICANN-LGR-SLA].

   If the changes specified in this document are not successful in
   significantly mitigating the confusion about the status of the tables
   published by IANA, serious consideration should be given to
   eliminating those tables entirely.

6.  Editorial Clarification to RFC 5892

   This section updates RFC 5892 to provide fixes for known applicable
   errata and omissions.  In particular, verified RFC Editor Erratum
   3312 [Err3312] provides a clarification to Appendix A and A.1 in RFC
   5892.  That clarification is incorporated below.

   1.  In Appendix A, add a new paragraph after the paragraph that
       begins "The code point...".  The new paragraph should read:

       |  For the rule to be evaluated to True for the label, it MUST be
       |  evaluated separately for every occurrence of the code point in
       |  the label; each of those evaluations must result in True.

   2.  In Appendix A.1, replace the "Rule Set" by

           Rule Set:
             False;
             If Canonical_Combining_Class(Before(cp)) .eq. Virama
                   Then True;
             If cp .eq. \u200C And
                    RegExpMatch((Joining_Type:{L,D})(Joining_Type:T)*cp
               (Joining_Type:T)*(Joining_Type:{R,D})) Then True;

7.  IANA Considerations

   For the algorithmic review described in Section 3.1, the IESG is to
   appoint a designated expert [RFC8126] with appropriate expertise to
   conduct the review and to supply derived property tables to IANA.  As
   provided in Section 5.2 of the Guidelines for Writing IANA
   Considerations [RFC8126], the designated expert is expected to
   consult additional sources of expertise as needed.  For the code
   point review, the expertise will be supplied by an IESG-designated
   expert team as discussed in Section 3.2 and Appendix B.  In both
   cases, the experts should draw on the expertise of other members of
   the community as needed.  In particular, and especially if there is
   no overlap of the people holding the various roles, coordination with
   the IAB-appointed liaison to the Unicode Consortium will be essential
   to mitigate possible errors due to confusion.

   As discussed in Section 5, IANA has modified the IDNA tables
   collection [IANA-IDNA-Tables] by identifying them clearly as non-
   normative, so that a "current" or "correct" version of those tables
   is not implied, and by pointing to this document for an explanation.
   IANA has published tables supplied by the IETF for all Unicode
   versions through 11.0, retaining all older versions and making them
   available.  Newer tables will be constructed as specified in this
   document and then made available by IANA.  IANA has changed the title
   of that registry from "IDNA Parameters", which is misleading, to
   "IDNA Rules and Derived Property Values".

   The "Note" in that registry says:

   |  IDNA does not require that applications and libraries, either for
   |  registration/storage or lookup, support any particular version of
   |  Unicode.  Instead, they are required to use derived property
   |  values based on calculations associated with whatever version of
   |  Unicode they are using elsewhere in the application or library.
   |  For the convenience of application and library developers and
   |  others, the IETF has supplied, and IANA maintains, derived
   |  property tables for several version of Unicode as listed below.
   |  It should be stressed that these are not normative in that, in
   |  principle, an application can do its own calculations and these
   |  tables can change as IETF understanding evolves.  By contrast, the
   |  list of code points requiring contextual rules and the associated
   |  rules are normative and should be treated as updates to the list
   |  in RFC 5892.

   As long as the intent is preserved, the text of that note may be
   changed in the future at IANA's discretion.

   IANA's attention is called to the introduction, in Section 3.2, of a
   temporary "under review" category to the PVALID, DISALLOWED, etc.,
   entries in the tables.

8.  Security Considerations

   Applying the procedures described in this document and understanding
   of the clarifications it provides should reduce confusion about IDNA
   requirements.  Because past confusion has provided opportunities for
   bad behavior, the effect of these changes should improve Internet
   security to at least some small extent.

   Because of the preference to keep the derived property value stable
   (as specified in RFC 5892 and discussed in Section 4), the algorithm
   used to calculate those derived properties does change as explained
   in Section 3.  If these changes are not taken into account, the
   derived property value will change, and the implications might have
   negative consequences, in some cases with security implications.  For
   example, changes in the calculated derived property value for a code
   point from either DISALLOWED to PVALID or from PVALID to DISALLOWED
   can cause changes in label interpretation that would be visible and
   confusing to end users and might enable attacks.

9.  References

9.1.  Normative References

   [IANA-IDNA-Tables]
              IANA, "IDNA Rules and Derived Property Values",
              <https://www.iana.org/assignments/idna-tables>.

   [RFC5892]  Faltstrom, P., Ed., "The Unicode Code Points and
              Internationalized Domain Names for Applications (IDNA)",
              RFC 5892, DOI 10.17487/RFC5892, August 2010,
              <https://www.rfc-editor.org/info/rfc5892>.

   [RFC5892a] Faltstrom, P., Ed., "The Unicode Code Points and
              Internationalized Domain Names for Applications (IDNA)",
              Section 2.7, RFC 5892, August 2010,
              <https://www.rfc-editor.org/rfc/rfc5892.txt>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [Unicode]  The Unicode Consortium, "The Unicode Standard (Current
              Version)", <http://www.unicode.org/versions/latest/>.  The
              link given will always access the current version of the
              Unicode Standard, independent of its version number or
              date.

   [Unicode-properties]
              The Unicode Consortium, "The Unicode Standard Version
              11.0", Section 3.5, 2018,
              <https://www.unicode.org/versions/Unicode11.0.0/>.

9.2.  Informative References

   [Err3312]  RFC Errata, Erratum ID 3312, RFC 5892,
              <https://www.rfc-editor.org/errata/eid3312>.

   [IAB-Unicode-2018]
              Internet Architecture Board (IAB), "IAB Statement on
              Identifiers and Unicode", 15 March 2018,
              <https://www.iab.org/documents/correspondence-reports-
              documents/2018-2/iab-statement-on-identifiers-and-
              unicode/>.

   [IAB-Unicode7-2015]
              Internet Architecture Board (IAB), "IAB Statement on
              Identifiers and Unicode 7.0.0", 11 February 2015,
              <https://www.iab.org/documents/correspondence-reports-
              documents/2015-2/iab-statement-on-identifiers-and-unicode-
              7-0-0/>.

   [ICANN-LGR-SLA]
              Internet Corporation for Assigned Names and Numbers
              (ICANN), "Proposed IANA SLAs for Publishing LGRs/IDN
              Tables", 10 June 2019, <https://www.icann.org/public-
              comments/proposed-iana-sla-lgr-idn-tables-2019-06-10-en>.

   [IDNA-Unicode7]
              Klensin, J. and P. Faltstrom, "IDNA Update for Unicode 7.0
              and Later Versions", Work in Progress, Internet-Draft,
              draft-klensin-idna-5892upd-unicode70-05, 8 October 2017,
              <https://tools.ietf.org/html/draft-klensin-idna-5892upd-
              unicode70-05>.

   [IDNA-Unicode11]
              Faltstrom, P., "IDNA2008 and Unicode 11.0.0", Work in
              Progress, Internet-Draft, draft-faltstrom-unicode11-08, 11
              March 2019, <https://tools.ietf.org/html/draft-faltstrom-
              unicode11-08>.

   [IDNA-Unicode12]
              Faltstrom, P., "IDNA2008 and Unicode 12.0.0", Work in
              Progress, Internet-Draft, draft-faltstrom-unicode12-00, 11
              March 2019, <https://tools.ietf.org/html/draft-faltstrom-
              unicode12-00>.

   [RegRestr] Klensin, J. and A. Freytag, "Internationalized Domain
              Names in Applications (IDNA): Registry Restrictions and
              Recommendations", Work in Progress, Internet-Draft, draft-
              klensin-idna-rfc5891bis-05, 29 August 2019,
              <https://tools.ietf.org/html/draft-klensin-idna-
              rfc5891bis-05>.

   [RFC1766]  Alvestrand, H., "Tags for the Identification of
              Languages", RFC 1766, DOI 10.17487/RFC1766, March 1995,
              <https://www.rfc-editor.org/info/rfc1766>.

   [RFC3282]  Alvestrand, H., "Content Language Headers", RFC 3282,
              DOI 10.17487/RFC3282, May 2002,
              <https://www.rfc-editor.org/info/rfc3282>.

   [RFC3454]  Hoffman, P. and M. Blanchet, "Preparation of
              Internationalized Strings ("stringprep")", RFC 3454,
              DOI 10.17487/RFC3454, December 2002,
              <https://www.rfc-editor.org/info/rfc3454>.

   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, DOI 10.17487/RFC3490, March 2003,
              <https://www.rfc-editor.org/info/rfc3490>.

   [RFC3491]  Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
              Profile for Internationalized Domain Names (IDN)",
              RFC 3491, DOI 10.17487/RFC3491, March 2003,
              <https://www.rfc-editor.org/info/rfc3491>.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <https://www.rfc-editor.org/info/rfc3629>.

   [RFC4690]  Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and
              Recommendations for Internationalized Domain Names
              (IDNs)", RFC 4690, DOI 10.17487/RFC4690, September 2006,
              <https://www.rfc-editor.org/info/rfc4690>.

   [RFC5646]  Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
              Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
              September 2009, <https://www.rfc-editor.org/info/rfc5646>.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,
              <https://www.rfc-editor.org/info/rfc5890>.

   [RFC5894]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Background, Explanation, and
              Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010,
              <https://www.rfc-editor.org/info/rfc5894>.

   [RFC6452]  Faltstrom, P., Ed. and P. Hoffman, Ed., "The Unicode Code
              Points and Internationalized Domain Names for Applications
              (IDNA) - Unicode 6.0", RFC 6452, DOI 10.17487/RFC6452,
              November 2011, <https://www.rfc-editor.org/info/rfc6452>.

Appendix A.  Summary of Changes to RFC 5892

   Other than the editorial correction specified in Section 6, all of
   the changes in this document are concerned with the reviews for new
   versions of Unicode and with the IANA Considerations in Section 5 of
   [RFC5892], particularly Section 5.1 of [RFC5892].  Whether the
   changes are substantive or merely clarifications may be somewhat in
   the eye of the beholder, so the list below should not be assumed to
   be comprehensive.  At a very high level, this document clarifies that
   two types of review were intended and separates them for clarity.
   This document also restores the original (but so far unobserved)
   default for actions when code point derived properties change.  For
   this reason, this document effectively replaces Section 5.1 of
   [RFC5892] and adds or changes some text so that the replacement makes
   better sense.

   Changes or clarifications that may be considered important include:

   *  Separated the new Unicode version review into two explicit parts
      and provided for different review methods and, potentially,
      asynchronous outcomes.

   *  Specified a DE team, not a single designated expert, for the code
      point review.

   *  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.

   *  Created the "Status" field in the IANA tables to inform the
      community about specific potentially problematic code points.
      This change creates the ability to add information about such code
      points before IETF review is completed instead of having the
      review process hold up the use of the new Unicode version.

   *  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 internationalization 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.

Appendix B.  Background and Rationale for Expert Review Procedure for
             New Code Point Analysis

   The expert review procedure for new code point analysis described in
   Section 3.2 is somewhat unusual compared to the examples presented in
   the Guidelines for Writing IANA Considerations [RFC8126].  This
   appendix explains that choice and provides the background for it.

   Development of specifications to support use of languages and writing
   systems other than English (and Latin script) -- so-called
   "internationalization" or "i18n" -- has always been problematic in
   the IETF, especially when requirements go beyond simple coding of
   characters (e.g., RFC 3629 [RFC3629]) or simple identification of
   languages (e.g., RFC 3282 [RFC3282] and the earlier RFC 1766
   [RFC1766]).  A good deal of specialized knowledge is required,
   knowledge that comes from multiple fields and that requires multiple
   perspectives.  The work is not obviously more complex than routing,
   especially if one assumes that routing work requires a solid
   foundation in graph theory or network optimization, or than security
   and cryptography, but people working in those areas are drawn to the
   IETF and people from the fields that bear on internationalization
   typically are not.

   As a result, we have often thought we understood a problem, generated
   a specification or set of specifications, but then have been
   surprised by unanticipated (by the IETF) issues.  We then needed to
   tune and often revise our specification.  The language tag work that
   started with RFC 1766 is a good example of this: broader
   considerations and requirements led to later work and a much more
   complex and finer-grained system [RFC5646].

   Work on IDNs further increased the difficulties because many of the
   decisions that led to the current version of IDNA require
   understanding the DNS, its constraints, and, to at least some extent,
   the commercial market of domain names, including various ICANN
   efforts.

   The net result of these factors is that it is extremely unlikely that
   the IESG will ever find a designated expert whose knowledge and
   understanding will include everything that is required.

   Consequently, Section 7 and other discussions in this document
   specify a DE team that is expected to have the broad perspective,
   expertise, and access to information and community in order to review
   new Unicode versions and to make consensus recommendations that will
   serve the Internet well.  While we anticipate that the team will have
   one or more leaders, the structure of the team differs from the
   suggestions given in Section 5.2 of the Guidelines for Writing IANA
   Considerations [RFC8126] since neither the team's formation nor its
   consultation is left to the discretion of the designated expert, nor
   is the designated expert solely accountable to the community.  A team
   that contains multiple perspectives is required, the team members are
   accountable as a group, and any nontrivial recommendations require
   team consensus.  This also differs from the common practice in the
   IETF of "review teams" from which a single member is selected to
   perform a review: the principle for these reviews is team effort.

Acknowledgments

   This document was inspired by extensive discussions within the I18N
   Directorate of the IETF Applications and Real-Time (ART) area in the
   first quarter of 2019 about sorting out the reviews for Unicode 11.0
   and 12.0.  Careful reviews by Joel Halpern and text suggestions from
   Barry Leiba resulted in some clarifications.

   Thanks to Christopher Wood for catching some editorial errors that
   persisted until rather late in the document's life cycle and to
   Benjamin Kaduk for catching and raising a number of questions during
   Last Call.  Some of the issues they raised have been reflected in the
   document; others did not appear to be desirable modifications after
   further discussion, but the questions were definitely worth raising
   and discussing.

Authors' Addresses

   John C Klensin
   1770 Massachusetts Ave, Ste 322
   Cambridge, MA 02140
   United States of America

   Phone: +1 617 245 1457
   Email: john-ietf@jck.com

   Patrik Fältström
   Netnod
   Greta Garbos Väg 13
   SE-169 40 Solna
   Sweden

   Phone: +46 70 6059051
   Email: paf@netnod.se