Internationalized Domain Names for Applications (IDNA) Review for New Unicode Versions1770 Massachusetts Ave, Ste 322CambridgeMA02140United States of America+1 617 245 1457john-ietf@jck.comNetnodGreta Garbos Väg 13Solna169 40Sweden+46 70 6059051paf@netnod.se
ART
IDNA2008IDNUnicode Algorithmic ReviewUnicode Code Point ReviewIDNA Designated ExpertThe 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
.
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
() 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
. Introduction
. Brief History of IDNA Versions, the Review Requirement, and RFC 5982
. The Review Model
. Review Model Part I: Algorithmic Comparison
. Review Model Part II: New Code Point Analysis
. IDNA Assumptions and Current Practice
. Derived Tables Published by IANA
. Editorial Clarification to RFC 5892
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
. Summary of Changes to RFC 5892
. Background and Rationale for Expert Review Procedure for New Code Point Analysis
Acknowledgments
Authors' Addresses
IntroductionThe 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
(see and
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
, 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
. Terminology note: In this document, "IDNA" refers to the
current version as described
in RFC 5890 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 .Brief History of IDNA Versions, the Review Requirement, and RFC 5982The original, now-obsolete, version of IDNA, commonly known
as "IDNA2003" , was defined in terms of a profile
of a collection of IETF-specific
tables 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 , 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 .
In the IDNA2008 model, the use of normative tables was
replaced by a set of procedures and rules that operated on
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 ). 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.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 () for details.Review Model Part I: Algorithmic ComparisonSection
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 , 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)
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 for further
discussion of these preferences. 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 .
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 . 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. 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 .
This has not been the practice in the reviews completed
subsequent to Unicode 5.2, as
discussed in .
Incompatibilities were identified in Unicode 6.0
and in the cumulative review
leading to tables for Unicode 11.0
.
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 , done catch-up
work between it and
Unicode 11.0 ,
and completed the review and tables for
Unicode 12.0 . 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 .
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 ) 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.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 . 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.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 provides a
clarification to Appendix
and in RFC 5892.
That clarification is incorporated below.
In Appendix , 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.
In Appendix , 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;
IANA Considerations For the algorithmic review described in
, the IESG is to appoint a
designated expert with appropriate
expertise to conduct the review and to supply derived property
tables to IANA. As provided in the Guidelines
for Writing IANA Considerations, 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 and
. 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 ,
IANA has modified the IDNA tables collection
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
, of a temporary "under
review" category to the PVALID, DISALLOWED, etc., entries
in the tables.Security ConsiderationsApplying 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 ), the
algorithm used to calculate those derived properties does
change as explained in . 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. ReferencesNormative ReferencesIDNA Rules and Derived Property ValuesIANAThe Unicode Code Points and Internationalized Domain Names for Applications (IDNA)This document specifies rules for deciding whether a code point, considered in isolation or in context, is a candidate for inclusion in an Internationalized Domain Name (IDN). It is part of the specification of Internationalizing Domain Names in Applications 2008 (IDNA2008). [STANDARDS-TRACK]The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)Section 2.7Guidelines for Writing an IANA Considerations Section in RFCsMany protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.This is the third edition of this document; it obsoletes RFC 5226.The Unicode Standard (Current Version)The Unicode ConsortiumThe link given will always access the current
version of the Unicode Standard, independent of its version
number or date.The Unicode Standard Version 11.0The Unicode ConsortiumSection 3.5Informative ReferencesErratum ID 3312RFC ErrataRFC 5892IAB Statement on Identifiers and UnicodeInternet Architecture Board (IAB)IAB Statement on Identifiers and Unicode 7.0.0Internet Architecture Board (IAB)Proposed IANA SLAs for Publishing LGRs/IDN TablesInternet Corporation for Assigned Names and Numbers (ICANN)IDNA Update for Unicode 7.0 and Later VersionsThe current version of the IDNA specifications anticipated that each new version of Unicode would be reviewed to verify that no changes had been introduced that required adjustments to the set of rules and, in particular, whether new exceptions or backward compatibility adjustments were needed. The review for Unicode 7.0.0 first identified a potentially problematic new code point and then a much more general and difficult issue with Unicode normalization. This specification discusses those issues and proposes updates to IDNA and, potentially, the way the IETF handles comparison of identifiers more generally, especially when there is no associated language or language identification. It also applies an editorial clarification to RFC 5892 that was the subject of an earlier erratum and updates RFC 5894 to point to the issues involved.Work in ProgressIDNA2008 and Unicode 11.0.0This document describes the changes between Unicode 6.3.0 and Unicode 11.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. 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 Unicode 11.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 i18nrp@ietf.org mailing list of the IETF.Work in ProgressIDNA2008 and Unicode 12.0.0This document describes the changes between Unicode 6.3.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. 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 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 i18nrp@ietf.org mailing list of the IETF.Work in ProgressInternationalized Domain Names in Applications (IDNA): Registry Restrictions and RecommendationsThe IDNA specifications for internationalized domain names combine rules that determine the labels that are allowed in the DNS without violating the protocol itself and an assignment of responsibility, consistent with earlier specifications, for determining the labels that are allowed in particular zones. Conformance to IDNA by registries and other implementations requires both parts. Experience strongly suggests that the language describing those responsibilities was insufficiently clear to promote safe and interoperable use of the specifications and that more details and discussion of circumstances would have been helpful. Without making any substantive changes to IDNA, this specification updates two of the core IDNA documents (RFCs 5890 and 5891) and the IDNA explanatory document (RFC 5894) to provide that guidance and to correct some technical errors in the descriptions.Work in ProgressTags for the Identification of LanguagesThis document describes a language tag for use in cases where it is desired to indicate the language used in an information object. [STANDARDS-TRACK]Content Language HeadersThis document defines a "Content-language:" header, for use in cases where one desires to indicate the language of something that has RFC 822-like headers, like MIME body parts or Web documents, and an "Accept-Language:" header for use in cases where one wishes to indicate one's preferences with regard to language. [STANDARDS-TRACK]Preparation of Internationalized Strings ("stringprep")This document describes a framework for preparing Unicode text strings in order to increase the likelihood that string input and string comparison work in ways that make sense for typical users throughout the world. The stringprep protocol is useful for protocol identifier values, company and personal names, internationalized domain names, and other text strings. This document does not specify how protocols should prepare text strings. Protocols must create profiles of stringprep in order to fully specify the processing options. [STANDARDS-TRACK]Internationalizing Domain Names in Applications (IDNA)Until now, there has been no standard method for domain names to use characters outside the ASCII repertoire. This document defines internationalized domain names (IDNs) and a mechanism called Internationalizing Domain Names in Applications (IDNA) for handling them in a standard fashion. IDNs use characters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII characters to be represented using only the ASCII characters already allowed in so-called host names today. This backward-compatible representation is required in existing protocols like DNS, so that IDNs can be introduced with no changes to the existing infrastructure. IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK]Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)This document describes how to prepare internationalized domain name (IDN) labels in order to increase the likelihood that name input and name comparison work in ways that make sense for typical users throughout the world. This profile of the stringprep protocol is used as part of a suite of on-the-wire protocols for internationalizing the Domain Name System (DNS). [STANDARDS-TRACK]UTF-8, a transformation format of ISO 10646ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.Review and Recommendations for Internationalized Domain Names (IDNs)IABThis note describes issues raised by the deployment and use of Internationalized Domain Names. It describes problems both at the time of registration and for use of those names in the DNS. It recommends that IETF should update the RFCs relating to IDNs and a framework to be followed in doing so, as well as summarizing and identifying some work that is required outside the IETF. In particular, it proposes that some changes be investigated for the Internationalizing Domain Names in Applications (IDNA) standard and its supporting tables, based on experience gained since those standards were completed. This memo provides information for the Internet community.Tags for Identifying LanguagesThis document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Internationalized Domain Names for Applications (IDNA): Definitions and Document FrameworkThis document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]Internationalized Domain Names for Applications (IDNA): Background, Explanation, and RationaleSeveral years have passed since the original protocol for Internationalized Domain Names (IDNs) was completed and deployed. During that time, a number of issues have arisen, including the need to update the system to deal with newer versions of Unicode. Some of these issues require tuning of the existing protocols and the tables on which they depend. This document provides an overview of a revised system and provides explanatory material for its components. This document is not an Internet Standards Track specification; it is published for informational purposes.The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0This memo documents IETF consensus for Internationalized Domain Names for Applications (IDNA) derived character properties related to the three code points, existing in Unicode 5.2, that changed property values when version 6.0 was released. The consensus is that no update is needed to RFC 5892 based on the changes made in Unicode 6.0. [STANDARDS-TRACK]Summary of Changes to RFC 5892 Other than the editorial correction specified in
, all of the changes in this
document are concerned with the reviews for new versions of
Unicode and with the IANA Considerations in
,
particularly . 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
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.
Background and Rationale for Expert Review Procedure for New Code Point Analysis The expert review procedure for new code point analysis described
in is somewhat unusual compared to the examples
presented in the Guidelines for Writing
IANA Considerations . 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) or simple
identification of languages (e.g.,
RFC 3282 and the earlier
RFC 1766). 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
. 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,
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 the Guidelines
for Writing IANA Considerations
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 and
text suggestions from resulted in some
clarifications. Thanks to for catching some editorial
errors that persisted until rather late in the document's
life cycle and to 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' Addresses1770 Massachusetts Ave, Ste 322CambridgeMA02140United States of America+1 617 245 1457john-ietf@jck.comNetnodGreta Garbos Väg 13Solna169 40Sweden+46 70 6059051paf@netnod.se