rfc8753xml2.original.xml   rfc8753.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- Getting references from the online citation library.
There has to be one entity for each item to be referenced. -->
<!ENTITY rfc1766 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.1766.xml">
<!ENTITY rfc3282 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.3282.xml">
<!ENTITY rfc3454 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.3454.xml">
<!ENTITY rfc3490 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.3490.xml">
<!ENTITY rfc3491 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.3491.xml">
<!ENTITY rfc3629 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.3629.xml">
<!ENTITY rfc4690 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.4690.xml">
<!ENTITY rfc5646 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.5646.xml">
<!ENTITY rfc5890 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.5890.xml">
<!ENTITY rfc5892 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.5892.xml">
<!ENTITY rfc5894 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.5894.xml">
<!ENTITY rfc6452 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.6452.xml">
<!ENTITY rfc8126 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.8126.xml">
<!-- Outline of entity definition for citations to Internet Drafts
&lt;!ENTITY I-D.mrose-writing-rfcs SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mrose-writing-rfc
s">
corresponding to a draft filename draft-mrose-writing-rfcs-nn.txt.
Naming convention for draft-ietf-xx-yy is that
ietf-xx-yy is latest version
draft-ietf-xx-yy-NN is that version. Similarly for draft-foo
rather than draft-ietf: foo-xx-yy and draft-foo-xx-yy-NN
-->
<!-- Fudge for XMLmind which doesn't have this built in -->
<!ENTITY nbsp "&#160;">
]>
<!-- Extra statement used by XSLT processors to control the output style. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Processing Instructions- PIs (for a complete list and description,
see file http://xml.resource.org/authoring/README.html.
You may find that some sphisticated editors are not able to edit PIs when p
alced here.
An alternative position is just inside the rfc elelment as noted below. -->
<!-- Some of the more generally applicable PIs that most I-Ds might want to use
-->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<!-- Controls display of <cref> elements -->
<?rfc comments="yes" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc inline="yes" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<?rfc editing="no" ?>
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists on
a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC.
Can be overridden by 'toc="include"/"exclude"' on the section
element-->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes"
also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not st
arting each
main section on a new page but does not omit the blank lines between list i
tems.
If subcompact is also "yes" the blank lines between list items are also omi
tted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- Information about the document.
category values: std, bcp, info, exp, and historic
For Internet-Drafts, specify attribute "ipr".
original ipr values are: full3978, noModification3978, noDerivatives397
8),
2008 IETF Trust versions: trust200811, noModificationTrust200811, noDer
ivativeTrust200811
2009/Current: trust200902, noModificationTrust200902, noDerivativesTrus
t200902, pre5378Trust200902
Also for Internet-Drafts, you must specify a value for attributes "docName"
which is
typically the file name under which it is filed but need not be.
If relevant, "iprExtract" may be specified to denote the anchor attribute v
alue of a
section that can be extracted for separate publication, it is only usefu
l when the value
of "ipr" does not give the Trust full rights.
"updates" and "obsoletes" attributes can also be specified here, their argu
ments are
comma-separated lists of RFC numbers (just the numbers) -->
<!-- This XML file is version -05x of the XML. It is identical to
-05b, the version posted 2019-11-03 and approved by the IESG,
except for the addition of keywords and adjustment of tracking
and editorial comments not relevant to RFC Editor processing.
This comment replaces earlier tracking information. In the text
below, tracking and editorial comments have been removed.
<rfc docName="draft-klensin-idna-unicode-review-05"
ipr="trust200902" category="std" updates="589">
<!-- obsoletes='2821, 821' updates='1123'
category='std' (bcp, info, exp, historic) -->
<!-- ***** FRONT MATTER ***** --> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc
xmlns:xi="http://www.w3.org/2001/XInclude"
number="8753"
docName="draft-klensin-idna-unicode-review-05"
ipr="trust200902"
category="std"
consensus="true"
updates="5892"
obsoletes=""
submissionType="IETF"
xml:lang="en"
tocInclude="true"
tocDepth="3"
symRefs="true"
sortRefs="false"
version="3">
<front> <front>
<title abbrev="IDNA Unicode Reviews">Internationalized Domain Names
<title abbrev="IDNA-Unicode Reviews">IDNA Review for New Unicode for Applications (IDNA) Review for New Unicode Versions</title>
Versions</title> <seriesInfo name="RFC" value="8753"/>
<author fullname="John C Klensin" initials="J." surname="Klensin">
<!-- add 'role="editor"' below for the editors if appropriate --> <organization/>
<author fullname="John C Klensin" initials="J.C." surname="Klensin"> <o
rganization/>
<address> <address>
<postal> <postal>
<street>1770 Massachusetts Ave, Ste 322</street> <street>1770 Massachusetts Ave, Ste 322</street>
<city>Cambridge</city> <region>MA</region> <city>Cambridge</city>
<region>MA</region>
<code>02140</code> <code>02140</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<phone>+1 617 245 1457</phone> <phone>+1 617 245 1457</phone>
<email>john-ietf@jck.com</email> <email>john-ietf@jck.com</email>
</address> </address>
</author> </author>
<author fullname="Patrik Faltstrom" initials="P." surname="Faltstrom"> <author fullname="Patrik Fältström" initials="P." surname="Fältström">
<organization>Netnod</organization> <organization>Netnod</organization>
<address> <address>
<postal> <postal>
<street>Franzengatan 5</street> <street>Greta Garbos Väg 13</street>
<city>Stockholm</city> <city>Solna</city>
<code>112 51</code> <code>169 40</code>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<phone>+46 70 6059051</phone> <phone>+46 70 6059051</phone>
<email>paf@netnod.se</email> <email>paf@netnod.se</email>
</address> </address>
</author> </author>
<date month="April" year="2020"/>
<date month="November" day="03" year="2019" />
<!-- Meta-data Declarations -->
<area>ART</area> <area>ART</area>
<keyword> IDNA2008 </keyword> <keyword> IDNA2008 </keyword>
<keyword> IDN </keyword> <keyword> IDN </keyword>
<keyword> Unicode Algorithmic Review</keyword> <keyword> Unicode Algorithmic Review</keyword>
<keyword> Unicode Code Point Review</keyword> <keyword> Unicode Code Point Review</keyword>
<keyword> IDNA Designated Expert </keyword> <keyword> IDNA Designated Expert </keyword>
<abstract> <abstract>
<t>The standards for Internationalized Domain Names in <t>The standards for Internationalized Domain Names in
Applications (IDNA) Applications (IDNA)
require a review of each new version of Unicode to determine require a review of each new version of Unicode to determine
whether incompatibilities with prior versions or other issues whether incompatibilities with prior versions or other issues
exist and, where appropriate, to allow the IETF to decide on exist and, where appropriate, to allow the IETF to decide on
the trade-offs between compatibility with prior IDNA versions the trade-offs between compatibility with prior IDNA versions
and compatibility with Unicode going forward. That and compatibility with Unicode going forward. That
requirement, and its relationship to tables maintained by requirement, and its relationship to tables maintained by
IANA, has caused significant confusion in the past. This IANA, has caused significant confusion in the past. This
skipping to change at line 162 skipping to change at line 71
Applications (IDNA) Applications (IDNA)
require a review of each new version of Unicode to determine require a review of each new version of Unicode to determine
whether incompatibilities with prior versions or other issues whether incompatibilities with prior versions or other issues
exist and, where appropriate, to allow the IETF to decide on exist and, where appropriate, to allow the IETF to decide on
the trade-offs between compatibility with prior IDNA versions the trade-offs between compatibility with prior IDNA versions
and compatibility with Unicode going forward. That and compatibility with Unicode going forward. That
requirement, and its relationship to tables maintained by requirement, and its relationship to tables maintained by
IANA, has caused significant confusion in the past. This IANA, has caused significant confusion in the past. This
document makes adjustments to the review procedure based on experience document makes adjustments to the review procedure based on experience
and updates IDNA, specifically RFC 5892, to reflect those and updates IDNA, specifically RFC 5892, to reflect those
changes and clarify the various relationships involved. It changes and to clarify the various relationships involved. It
also makes other minor adjustments to align that document also makes other minor adjustments to align that document
with experience. </t> with experience. </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t>The standards for Internationalized Domain Names in <t>The standards for Internationalized Domain Names in
Applications (IDNA) require a review of each new version of Applications (IDNA) require a review of each new version of
Unicode to determine whether incompatibilities with prior Unicode to determine whether incompatibilities with prior
versions or other issues exist and, where appropriate, to versions or other issues exist and, where appropriate, to
allow the IETF to decide on the trade-offs between allow the IETF to decide on the trade-offs between
compatibility with prior IDNA versions and compatibility compatibility with prior IDNA versions and compatibility
with Unicode <xref target="Unicode"/> going forward. That with Unicode <xref target="Unicode" format="default"/> going forward. That
requirement, and its relationship to tables maintained by requirement, and its relationship to tables maintained by
IANA, has caused significant confusion in the past IANA, has caused significant confusion in the past
(see <xref target="ReviewModel"/> and (see <xref target="ReviewModel" format="default"/> and
<xref target="IDNA-Assumptions"/> for additional discussion <xref target="IDNA-Assumptions" format="default"/> for additiona
l discussion
of the question of appropriate decisions and the history of of the question of appropriate decisions and the history of
these reviews). these reviews).
This This
document makes adjustments to the review procedure based on document makes adjustments to the review procedure based on
nearly a decade of experience and updates IDNA, specifically nearly a decade of experience and updates IDNA, specifically
the document that specifies the relationship between Unicode the document that specifies the relationship between Unicode
code points and IDNA derived properties code points and IDNA derived properties
<xref target="RFC5892"/>, to reflect those <xref target="RFC5892" format="default"/>, to reflect those
changes and clarify the various relationships involved. </t> changes and to clarify the various relationships involved. </t>
<t> This specification does not change the requirement that
<t> This specification does not change the requirement that registries at all levels of the DNS tree take
registries, at all levels of the DNS tree, take responsibility for the labels they insert in the DNS,
responsibility for the labels they are inserting in the DNS,
a level of responsibility that requires allowing only a a level of responsibility that requires allowing only a
subset of the code points and strings allowed by the IDNA subset of the code points and strings allowed by the IDNA
protocol itself. That requirement is discussed in more protocol itself. That requirement is discussed in more
detail in a companion document detail in a companion document
<xref target="RegRestr"/>.</t> <xref target="I-D.klensin-idna-rfc5891bis" format="default"/>.</
t>
<t> Terminology note: In this document, "IDNA" refers to the <t> Terminology note: In this document, "IDNA" refers to the
current version as described current version as described
in <xref target="RFC5890">RFC 5890</xref> and subsequent in <xref target="RFC5890" format="default">RFC 5890</xref> and subseque nt
documents and sometimes known as "IDNA2008". Distinctions documents and sometimes known as "IDNA2008". Distinctions
between it and the earlier version are explicit only where between it and the earlier version are explicit only where
that is necessary to understanding the relationships they are necessary for understanding the relationships
involved, e.g., in <xref target="History"/>.</t> involved, e.g., in <xref target="History" format="default"/>.</t>
</section> </section>
<section anchor="History" numbered="true" toc="default">
<section title="Brief History of IDNA Versions, the Review Requirement, and <name>Brief History of IDNA Versions, the Review Requirement, and RFC 5982
RFC 5982" </name>
anchor="History"> <t>The original, now-obsolete, version of IDNA, commonly known
<t>The original, now-obsolete, version of IDNA, commonly known as "IDNA2003" <xref target="RFC3490" format="default"/>
as "IDNA2003" <xref target="RFC3490"/> <xref target="RFC3491" format="default"/>, was defined in terms of a pro
<xref target="RFC3491"/>, was defined in terms of a profile file
of a collection of IETF-specific of a collection of IETF-specific
tables <xref target="RFC3454"/> that specified the usability tables <xref target="RFC3454" format="default"/> that specified the us ability
of each Unicode code point with IDNA. Because the tables of each Unicode code point with IDNA. Because the tables
themselves were normative, they were intrinsically tied to a themselves were normative, they were intrinsically tied to a
particular version of Unicode. As Unicode evolved, the particular version of Unicode. As Unicode evolved, the
standard would either have required a new version for each IDNA2003 standard would have required the creation of a
new version of Unicode or it would fall further and further new profile for each new version of Unicode, or the
behind. </t> tables would have fallen further and further behind.</t>
<!-- Note to RFC Editor: "the standard" is not capitalized (or <t> When IDNA2003 was superseded by the
is) consistently in this document. Please figure out what current version, known as IDNA2008 <xref target="RFC5890" format="defa
you'd like and adjust accordingly. --> ult"/>, a
<t> When that version of IDNA was superseded by the
current one, known as IDNA2008 <xref target="RFC5890"/>, a
different strategy, one that was property-based rather than different strategy, one that was property-based rather than
table-based, was adopted for a number of reasons of which table-based, was adopted for a number of reasons, of which
the reliance on normative the reliance on normative
tables was not dominant <xref target="RFC4690"/>. tables was not dominant <xref target="RFC4690" format="default"/>.
In the IDNA2008 model, the use of normative tables was In the IDNA2008 model, the use of normative tables was
replaced by a set of procedures and rules that operated on replaced by a set of procedures and rules that operated on
Unicode properties <xref target="Unicode-properties"/> and Unicode properties <xref target="Unicode-properties" format="default"/ > and
a few internal definitions to determine the category and a few internal definitions to determine the category and
status, and hence an IDNA-specific "derived property", for status, and hence an IDNA-specific "derived property", for
any given code point. any given code point.
Those rules are, in principle, independent of Unicode Those rules are, in principle, independent of Unicode
versions. They can be applied to any version of Unicode, at versions. They can be applied to any version of Unicode, at
least from approximately version 5.0 forward, to yield least from approximately version 5.0 forward, to yield
an appropriate set of derived properties. However, the an appropriate set of derived properties. However, the
working group that defined IDNA2008 recognized that not all working group that defined IDNA2008 recognized that not all
of the Unicode properties were completely stable and that, of the Unicode properties were completely stable and that,
because the criteria for new code points and property because the criteria for new code points and property
assignment used by the Unicode Consortium might not assignment used by the Unicode Consortium might not
precisely align with the needs of IDNA, there were precisely align with the needs of IDNA, there were
possibilities of incompatible changes to the derived property possibilities of incompatible changes to the derived property
value. values.
More specifically, there could be changes that would make More specifically, there could be changes that would make
previously-disallowed labels valid, previously-valid labels previously disallowed labels valid, previously valid labels
disallowed, or that would be disruptive to IDNA's defining disallowed, or that would be disruptive to IDNA's defining
rule structure. rule structure.
Consequently, IDNA2008 provided for an Consequently, IDNA2008 provided for an
expert review of each new version of Unicode with the expert review of each new version of Unicode with the
possibility of providing exceptions to the rules for possibility of providing exceptions to the rules for
particular new code points, code points whose properties had particular new code points, code points whose properties had
changed, and newly-discovered issues with the IDNA2008 changed, and newly discovered issues with the IDNA2008
collection of rules. When problems were identified, the collection of rules. When problems were identified, the
reviewer was expected to notify the IESG. The reviewer was expected to notify the IESG. The
assumption was that the IETF would review the situation and assumption was that the IETF would review the situation and
modify IDNA2008 as needed, most likely by adding exceptions modify IDNA2008 as needed, most likely by adding exceptions
to preserve backward to preserve backward
compatibility (see <xref target="AlgorReview"/> compatibility (see <xref target="AlgorReview" format="default"/>).</t>
below).</t> <t> For the convenience of the community, IDNA2008 also
<t> For the convenience of the community, IDNA2008 also
provided that IANA would maintain copies of calculated tables provided that IANA would maintain copies of calculated tables
resulting from each review, showing the derived properties resulting from each review, showing the derived properties
for each code point. Those tables were expected to be for each code point. Those tables were expected to be
helpful, especially to those without the facilities to helpful, especially to those without the facilities to
easily compute derived properties themselves. Experience easily compute derived properties themselves. Experience
with the community and those tables has shown that they have with the community and those tables has shown that they have
been confused with the normative tables of IDNA2003: the been confused with the normative tables of IDNA2003: the
IDNA2008 tables published by IANA have never been normative IDNA2008 tables published by IANA have never been normative,
and statements about IDNA2008 being out of date with regard and statements about IDNA2008 being out of date with regard
to some Unicode version because the IANA tables have not to some Unicode version because the IANA tables have not
been updated are incorrect or meaningless.</t> been updated are incorrect or meaningless.</t>
</section> </section>
<section anchor="ReviewModel" numbered="true" toc="default">
<section title="The Review Model" anchor="ReviewModel"> <name>The Review Model</name>
<t> While the text has sometimes been interpreted differently, <t> While the text has sometimes been interpreted differently,
IDNA2008 actually calls for two types of review when a new IDNA2008 actually calls for two types of review when a new
Unicode version is introduced. One is an algorithmic Unicode version is introduced. One is an algorithmic
comparison of the set of derived properties calculated from comparison of the set of derived properties calculated from
the new version of Unicode to the derived properties the new version of Unicode to the derived properties
calculated from the previous one to determine whether calculated from the previous one to determine whether
incompatible changes have occurred. The other is a review of incompatible changes have occurred. The other is a review of
newly-assigned code points to determine whether any of them newly assigned code points to determine whether any of them
require special treatment (e.g., assignment of what IDNA2008 require special treatment (e.g., assignment of what IDNA2008
calls contextual rules) and whether any of them violate any of calls contextual rules) and whether any of them violate any of
the assumptions underlying the IDNA2008 derived property the assumptions underlying the IDNA2008 derived property
calculations. Any of the cases of either review might calculations. Any of the cases of either review might
require either per-code point exceptions or require either per-code point exceptions or
other adjustments to the rules for deriving properties other adjustments to the rules for deriving properties
that are part of RFC 5892. The subsections below that are part of RFC 5892. The subsections below
provide a revised specification for the review procedure.</t> provide a revised specification for the review procedure.</t>
<t> Unless the IESG or the Designated Expert conclude that there <t> Unless the IESG or the designated expert team concludes that there
are special problems or unusual circumstances, these reviews are special problems or unusual circumstances, these reviews
will be performed only for major Unicode versions (those will be performed only for major Unicode versions (those
numbered NN.0, e.g., 12.0) numbered NN.0, e.g., 12.0)
and not for minor updates (e.g., 12.1). </t> and not for minor updates (e.g., 12.1). </t>
<t> As can be seen in the detailed descriptions in the
<t> As can be seen in the detailed descriptions in the following subsections, proper review will require a team of
following sections, proper review will require a team of
experts that has both broad and specific skills in reviewing experts that has both broad and specific skills in reviewing
Unicode characters and their properties in relation to both Unicode characters and their properties in relation to both
the written standards and operational needs. The IESG will the written standards and operational needs. The IESG will
need to appoint experts who can draw on the broader need to appoint experts who can draw on the broader
community to obtain the necessary skills for particular community to obtain the necessary skills for particular
situations. See the situations. See the
IANA Considerations (<xref target="IANA"/>) for details.</t> IANA Considerations (<xref target="IANA" format="default"/>) for
details.</t>
<section title="Review Model Part I: Algorithmic Comparison" <section anchor="AlgorReview" numbered="true" toc="default">
anchor="AlgorReview"> <name>Review Model Part I: Algorithmic Comparison</name>
<t> Section 5.1 of RFC 5892 is the description of the process <t>Section <xref target="RFC5892" section="5.1" sectionFormat="bare" for
mat="default"/>
of RFC 5892 is the description of the process
for creating the initial IANA tables. It is noteworthy for creating the initial IANA tables. It is noteworthy
that, while it can be read as strongly implying new that, while it can be read as strongly implying new
reviews and new tables for versions of Unicode after 5.2, reviews and new tables for versions of Unicode after 5.2,
it does not explicitly specify those reviews or, e.g., the it does not explicitly specify those reviews or, e.g., the
timetable for completing them. It also indicates that timetable for completing them. It also indicates that
incompatibilities are to be "flagged for the IESG" but incompatibilities are to be "flagged for the IESG" but
does not specify exactly what the IESG is to do about them does not specify exactly what the IESG is to do about them
and when. For reasons related to the other type of review and when. For reasons related to the other type of review
and discussed below, only one review was and discussed below, only one review was
completed, documented <xref target="RFC6452"/>, and a set completed, documented <xref target="RFC6452" format="default"/>, and
of corresponding new tables installed. That review, for a set
of corresponding new tables installed. That review, which was for
Unicode 6.0, found only three incompatibilities; the Unicode 6.0, found only three incompatibilities; the
consensus was to ignore them (not create exceptions in consensus was to ignore them (not create exceptions in
IDNA2008) and remain consistent with computations based on IDNA2008) and to remain consistent with computations based on
current (Unicode 6.0) properties rather than preserving current (Unicode 6.0) properties rather than preserving
backward compatibility within IDNA. The 2018 review backward compatibility within IDNA. The 2018 review
(for Unicode 11.0 and versions in between it and 6.0) (for Unicode 11.0 and versions in between it and 6.0)
<xref target="IDNA-Unicode12"/> also concluded that <xref target="I-D.faltstrom-unicode12" format="default"/> also concl uded that
Unicode compatibility, rather than IDNA backward Unicode compatibility, rather than IDNA backward
compatibility, should be maintained. That decision was compatibility, should be maintained. That decision was
partially driven by the long period between reviews and partially driven by the long period between reviews and
the concern that table calculations by others in the the concern that table calculations by others in the
interim could result in unexpected incompatibilities if interim could result in unexpected incompatibilities if
derived property definitions where then changed. derived property definitions were then changed.
See <xref target="IDNA-Assumptions"/> for further See <xref target="IDNA-Assumptions" format="default"/> for further
discussion of these preferences. </t> discussion of these preferences. </t>
</section> </section>
<section anchor="CodePointReview" numbered="true" toc="default">
<section title="Review Model Part II: New Code Point Analysis" <name>Review Model Part II: New Code Point Analysis</name>
anchor="CodePointReview"> <t>
<t> The second type of review is not clearly explained in The second type of review, which is not clearly explained in
RFC 5892, but is intended to identify cases in which RFC 5892, is intended to identify cases in which newly added or
newly-added code points, or perhaps even newly-discovered recently discovered problematic code points violate the design
problematic older ones, violate design assumptions of assumptions of IDNA, to identify defects in those assumptions, or
IDNA, identify defects in those assumptions, or are to identify inconsistencies (from an IDNA perspective) with
inconsistent (from an IDNA perspective) with Unicode Unicode commitments about assignment, properties, and stability of
commitments about assignment, properties, and stability newly added code points. One example of this type of review was
of newly-added code points. the discovery of new code points after Unicode 7.0 that were
The discovery after Unicode 7.0 potentially visually equivalent, in the same script, to
was released that new code points were being added that previously available code point sequences <xref target="IAB-Unicode7-2015" fo
were potentially visually equivalent, in the same script, rmat="default"/>
to previously-available code point sequences was one <xref target="I-D.klensin-idna-5892upd-unicode70" format="default"/>.</t>
example of the type of situation the review was expected <t>
to discover (and did so Because multiple perspectives on Unicode and writing systems are
<xref target="IAB-Unicode7-2015"/> <xref target="IDNA-Unicode7"/>).< required, this review will not be successful unless it is done by
/t> a team. Finding one all-knowing expert is improbable, and a
<t> Because multiple perspectives on Unicode and writing single expert is unlikely to produce an adequate analysis.
systems are required, this review will not be successful
unless done by a team -- a single, all-knowing, Designated
Expert is not feasible or likely to produce an adequate
analysis.
Rather than any single expert being the sole source of Rather than any single expert being the sole source of
analysis, the designated expert team needs to understand analysis, the designated expert (DE) team needs to unders tand
that there will always be gaps in their knowledge, to that there will always be gaps in their knowledge, to
know what they don't know, and to work to find the know what they don't know, and to work to find the
expertise that each review requires. It is also expertise that each review requires. It is also
important that the DE team maintains close contact with important that the DE team maintains close contact with
the Area Directors and that the ADs remain aware of the the Area Directors (ADs) and that the ADs remain aware of
team's changing needs, reviewing and adjusting the team's the
membership over time, with periodic reviews at least team's changing needs, examining and adjusting the team's
membership over time, with periodic reexamination at leas
t
annually. annually.
It should also be recognized that, if this It should also be recognized that, if this
review identifies a problem, that problem is likely to review identifies a problem, that problem is likely to
be complex and/or involve multiple trade-offs. Actions to be complex and/or involve multiple trade-offs. Actions to
deal with it are likely to be disruptive (although perhaps deal with it are likely to be disruptive (although perhaps
not to large communities of users) or to leave either not to large communities of users), or to leave
security risks (opportunities for attacks and inadvertent security risks (opportunities for attacks and inadvertent
confusion as expected matches do not occur) or excessive confusion as expected matches do not occur), or to cause excessive
reliance on registries understanding and taking reliance on registries understanding and taking
responsibility for what they are registering responsibility for what they are registering <xref target="RFC5894"
<xref target="RFC5894"/> <xref target="RegRestr"/>. The format="default"/>
<xref target="I-D.klensin-idna-rfc5891bis" format="default"/>. The
latter, while a requirement of IDNA, has often not worked latter, while a requirement of IDNA, has often not worked
out well in the past.</t> out well in the past.</t>
<t>Because resolution of problems identified by this part of
<t>Because resolution of problems identified by this part of
the review may take some time even if that resolution is the review may take some time even if that resolution is
to add additional contextual rules or disallow one or more to add additional contextual rules or to disallow one or more
code points, there will be cases in which it will be code points, there will be cases in which it will be
appropriate to publish the results of the algorithmic appropriate to publish the results of the algorithmic
review and provide IANA with corresponding tables, with review and to provide IANA with corresponding tables, with
warnings about code points whose status is uncertain until warnings about code points whose status is uncertain until
there are IETF consensus conclusions about how to proceed . there is IETF consensus about how to proceed.
The affected code points should be considered unsafe and The affected code points should be considered unsafe and
identified as "under review" in the IANA tables until identified as "under review" in the IANA tables until
final derived properties are assigned. </t> final derived properties are assigned. </t>
</section> </section>
</section> </section>
<section anchor="IDNA-Assumptions" numbered="true" toc="default">
<section title="IDNA Assumptions and Current Practice" <name>IDNA Assumptions and Current Practice</name>
anchor="IDNA-Assumptions"> <t> At the time the IDNA2008 documents were written, the
<t> At the time the IDNA2008 documents were written, the
assumption was that, if new versions of Unicode introduced assumption was that, if new versions of Unicode introduced
incompatible changes, the Standard would be updated to preserve incompatible changes, the Standard would be updated to preserve
backward compatibility for users of IDNA. For most backward compatibility for users of IDNA. For most
purposes, this would be done by adding to the table of purposes, this would be done by adding to the table of
exceptions associated with Rule G <xref target="RFC5892a"/>. exceptions associated with Rule G <xref target="RFC5892a" format="defa
<!-- (Section 2.7 of RFC 5892).--> ult"/>.
</t> </t>
<t>This has not been the practice in the reviews completed <t>This has not been the practice in the reviews completed
subsequent to Unicode 5.2, as subsequent to Unicode 5.2, as
discussed in <xref target="ReviewModel"/>. discussed in <xref target="ReviewModel" format="default"/>.
Incompatibilities were identified in Unicode 6.0 Incompatibilities were identified in Unicode 6.0
<xref target="RFC6452"/>, in the cumulative review <xref target="RFC6452" format="default"/> and in the cumulative review
leading to tables for Unicode 11.0 leading to tables for Unicode 11.0
<xref target="ID.draft-faltstrom-unicode11"/>. <xref target="I-D.faltstrom-unicode11" format="default"/>.
In all of those cases, the decision was made to maintain In all of those cases, the decision was made to maintain
compatibility with Unicode properties rather than with prior compatibility with Unicode properties rather than with prior
versions of IDNA.</t> versions of IDNA.</t>
<t> Subsequent to the publication of this document, changes in <t> If an algorithmic review detects changes in Unicode
Unicode detected by algorithmic reviews that would break after version 12.0 that would break compatibility with
compatibility with derived properties associated with prior derived properties associated with prior versions of
versions of Unicode or that preserve such compatibility Unicode or changes that would preserve compatibility
within IDNA at the price of departing from current Unicode within IDNA at the cost of departing from current
specifications must be documented (in documents expected to Unicode specifications, those changes must be captured
be published as standards track RFCs), explained to, and in documents expected to be published as Standards Track
reviewed by the IETF.</t> RFCs so that the IETF can review those changes
<!-- RFC Editor: The above sentence is a horror, but I have and maintain a historical record.</t>
not been able to do much better. Please have a go at it <t> The community has now made decisions and updated tables
if you have less-bad ideas --> for Unicode 6.0 <xref target="RFC6452" format="default"/>, done
<t> The community has now made decisions and updated tables catch-up
for Unicode 6.0 <xref target="RFC6452"/>, done catch-up
work between it and work between it and
Unicode 11.0 <xref target="ID.draft-faltstrom-unicode11"/>, Unicode 11.0 <xref target="I-D.faltstrom-unicode11" format="def ault"/>,
and completed the review and tables for and completed the review and tables for
Unicode 12.0 <xref target="IDNA-Unicode12"/>. The Unicode 12.0 <xref target="I-D.faltstrom-unicode12" format="def ault"/>. The
decisions made in those cases were driven by preserving decisions made in those cases were driven by preserving
consistency with Unicode and Unicode property changes for consistency with Unicode and Unicode property changes for
reasons most clearly explained reasons most clearly explained
by the IAB <xref target="IAB-Unicode-2018"/>. Doing things by the IAB <xref target="IAB-Unicode-2018" format="default"/>.
that way is not only at variance with the language These actions were not only at variance with the language
in RFC 5892 but is also inconsistent with in RFC 5892 but were also inconsistent with commitments to
commitments to the registry and user communities to ensure the registry and user communities to ensure that IDN labels
that IDN labels, once valid under IDNA2008, would remain that were once valid under IDNA2008 would remain valid, and
valid and, excepting those that were invalid because they previously invalid labels would remain invalid, except for
contained unassigned code points, those that were invalid those labels that were invalid because they contained
remained invalid.</t> unassigned code points.</t>
<t> This document restores and clarifies that original language
<t> This document restores and clarifies that original language
and intent: absent extremely strong evidence on a and intent: absent extremely strong evidence on a
per-code point basis that preserving per-code point basis that preserving
the validity status of possible existing (or prohibited) the validity status of possible existing (or prohibited)
labels would cause significant harm, Unicode changes that labels would cause significant harm, Unicode changes that
would affect IDNA derived properties are to be reflected in would affect IDNA derived properties are to be reflected in
IDNA exceptions that preserve the status of those labels. IDNA exceptions that preserve the status of those labels.
There is one partial exception to this principle. If the There is one partial exception to this principle. If the
new code point new code point
analysis (see <xref target="CodePointReview"/>) concludes analysis (see <xref target="CodePointReview" format="default"/> ) concludes
that some code that some code
points or collections of code points should be further points or collections of code points should be further
analyzed, those code points, and labels including them, analyzed, those code points, and labels including them,
should be considered unsafe and used only with extreme caution should be considered unsafe and used only with extreme caution
because the conclusions of the analysis may change their because the conclusions of the analysis may change their
derived property values and status.</t> derived property values and status.</t>
</section> </section>
<section anchor="IANATables" numbered="true" toc="default">
<section title="Derived Tables Published by IANA" <name>Derived Tables Published by IANA</name>
anchor="IANATables"> <t> As discussed above, RFC 5892 specified that derived
<t> As discussed above, RFC 5892 specified that derived
property tables be provided via an IANA registry. Perhaps property tables be provided via an IANA registry. Perhaps
because most IANA registries are considered normative and because most IANA registries are considered normative and
authoritative, that registry has been the source of authoritative, that registry has been the source of
considerable confusion, including the incorrect assumption that the considerable confusion, including the incorrect assumption that the
absence of published tables for versions of Unicode later absence of published tables for versions of Unicode later
than 6.0 meant that IDNA could not be used with later than 6.0 meant that IDNA could not be used with later
versions. versions.
That position was raised in multiple ways, not all of them That position was raised in multiple ways, not all of them
consistent, especially in the ICANN consistent, especially in the ICANN
context <xref target="ICANN-LGR-SLA"/>. </t> context <xref target="ICANN-LGR-SLA" format="default"/>. </t>
<t> If the changes specified in this document are not <t> If the changes specified in this document are not
successful in significantly mitigating the confusion about successful in significantly mitigating the confusion about
the status of the tables published by IANA, serious the status of the tables published by IANA, serious
consideration should be given to eliminating those tables consideration should be given to eliminating those tables
entirely.</t> entirely.</t>
</section> </section>
<section anchor="ApplyErratum" numbered="true" toc="default">
<section title="Editorial clarification to RFC 5892" <name>Editorial Clarification to RFC 5892</name>
anchor="ApplyErratum"> <t> This section updates RFC 5892 to provide fixes for known
<t> In order to avoid this document going forward with applicable errata and omissions. In particular, verified RFC Editor
remaining known errors or omissions in RFC 5892, this Erratum 3312 <xref target="Err3312" format="default"/> provides a
section updates that document to provide fixes to known clarification to Appendix <xref target="RFC5892" section="A" sectionFo
applicable errata. In particular, verified RFC Editor rmat="bare" format="default"/>
Erratum 3312 <xref target="RFC5892Erratum"/> provides a and <xref target="RFC5892" section="A.1" sectionFormat="bare" format="
clarification to Appendix A and Section A.1 of RFC 5892. default"/> in RFC 5892.
That clarification is resolved below.</t> That clarification is incorporated below.</t>
<t><list style="numbers"> <ol spacing="normal" type="1">
<t> In Appendix A, add a new paragraph after the paragraph <li>
<t> In Appendix <xref target="RFC5892" section="A" sectionFormat="bare
" format="default"/>, add a new paragraph after the paragraph
that begins "The code point...". The new paragraph that begins "The code point...". The new paragraph
should read: should read: </t>
<vspace blankLines="1"/> <blockquote>
"For the rule to be evaluated to True for the label, it MUST be For the rule to be evaluated to True for the label, it <bcp14>MUST<
evaluated separately for every occurrence of the Code point in t /bcp14> be
he evaluated separately for every occurrence of the code point in the
label; each of those evaluations must result in label; each of those evaluations must result in True.</blockquote>
True."</t> </li>
<t> In Appendix A, Section A.1, replace the "Rule Set" by <li>
<figure><artwork> <t> In Appendix <xref target="RFC5892" section="A.1" sectionFormat="ba
re" format="default"/>, replace the "Rule Set" by
</t>
<sourcecode type="pseudocode"><![CDATA[
Rule Set: Rule Set:
False; False;
If Canonical_Combining_Class(Before(cp)) .eq. Virama If Canonical_Combining_Class(Before(cp)) .eq. Virama
Then True; Then True;
If cp .eq. \u200C And If cp .eq. \u200C And
RegExpMatch((Joining_Type:{L,D})(Joining_Type:T)*cp RegExpMatch((Joining_Type:{L,D})(Joining_Type:T)*cp
(Joining_Type:T)*(Joining_Type:{R,D})) Then True; (Joining_Type:T)*(Joining_Type:{R,D})) Then True; ]]></sourcecode>
</artwork></figure> </li>
</t></list></t> </ol>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t> 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.</t>
<t> Thanks to Christopher Wood for catching some editorial
errors that persisted until rather late in the draft'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
appear to be desirable modifications after further discussion
but the questions were definitely worth raising and
discussion.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t> For the algorithmic review described in <t> For the algorithmic review described in
<xref target="AlgorReview"/>, the IESG is to appoint a <xref target="AlgorReview" format="default"/>, the IESG is to ap
Designated Expert <xref target="RFC8126"/> with appropriate point a
expertise to conduct the review and supply derived property designated expert <xref target="RFC8126" format="default"/> with
tables to IANA. As provided in Section 5.2 of the Guidelines appropriate
for Writing IANA Considerations <xref target="RFC8126"/>, the expertise to conduct the review and to supply derived property
Designated Expert is expected to consult additional sources tables to IANA. As provided in <xref target="RFC8126"
section="5.2" sectionFormat="of">the Guidelines
for Writing IANA Considerations</xref>, the
designated expert is expected to consult additional sources
of expertise as needed. For the code point review, the expertis e of expertise as needed. For the code point review, the expertis e
will be supplied by an IESG-designated expert team as will be supplied by an IESG-designated expert team as
discussed in <xref target="CodePointReview"/> and discussed in <xref target="CodePointReview" format="default"/> a
<xref target="ExpertRationale"/>. In both nd
<xref target="ExpertRationale" format="default"/>. In both
cases, the experts should draw on the expertise of other cases, the experts should draw on the expertise of other
members of the community as needed. In particular, and members of the community as needed. In particular, and
especially if there is no overlap in the people holding the especially if there is no overlap of the people holding the
various roles, coordination with the IAB-appointed liaison various roles, coordination with the IAB-appointed liaison
to the Unicode Consortium will be essential to mitigate to the Unicode Consortium will be essential to mitigate
possible errors due to confusion.</t> possible errors due to confusion.</t>
<!-- RFC Editor: please align tense in the next paragraph if
IANA has completed this action prior to publication --> <t>As discussed in <xref target="IANATables" format="default"/>,
<t>As discussed in <xref target="IANATables"/>, and if they have IANA has modified the IDNA tables collection
not already done so, IANA is requested to modify the IDNA <xref target="IANA-IDNA-Tables" format="default"/> by identifying
tables collection <xref target="IANA-IDNA-Tables"/> to identify them clearly as non-normative, so that
them clearly as non-normative and in a way that drops the a "current" or "correct" version of those tables is not implied, and by
idea of a "current" or "correct" version of those tables, pointing to this document for an explanation.
pointing to this document for an explanation. That includes IANA has published tables supplied by the IETF for all
publishing and retaining tables, as supplied by the IETF's Unicode versions through 11.0, retaining all older
Designated Expert, for each new version of Unicode after this versions and making them available. Newer tables will
document is published, keeping all older versions be constructed as specified in this document and then
available. IANA is also requested to change the current made available by IANA. IANA has changed the
title of that registry from "IDNA Parameters", which is title of that registry from "IDNA Parameters", which is
misleading, to "IDNA Rules and Derived Property Values". </t> misleading, to "IDNA Rules and Derived Property Values". </t>
<t> The "Note" in that registry should also be revised to be <t> The "Note" in that registry says:
consistent with the above, perhaps to say: </t>
<list style="empty"> <blockquote>
<t> "IDNA does not require that applications and <t>IDNA does not require that applications and
libraries, either for registration/storage or lookup, libraries, either for registration/storage or lookup,
support any particular version of Unicode. Instead, support any particular version of Unicode. Instead,
they are required to use derived property values based they are required to use derived property values based
on calculations associated with whatever version of on calculations associated with whatever version of
Unicode they are using elsewhere in the application or Unicode they are using elsewhere in the application or
library. For the convenience of application and library. For the convenience of application and
library developers and others, the IETF has supplied, library developers and others, the IETF has supplied,
and IANA maintains, derived property tables for and IANA maintains, derived property tables for
several version of Unicode as listed below. It should several version of Unicode as listed below. It should
be stressed that these are not normative in that, in be stressed that these are not normative in that, in
principle, an application can do its own calculations principle, an application can do its own calculations
and these tables can change as IETF understanding and these tables can change as IETF understanding
evolves. By contrast, the list of code points evolves. By contrast, the list of code points
requiring contextual rules and the associated rules are requiring contextual rules and the associated rules are
normative and should be treated as updates to the list normative and should be treated as updates to the list
in RFC 5892."</t> in RFC 5892.</t>
</list></t> </blockquote>
<t> As long as the intent is preserved, the specific text is <t> As long as the intent is preserved, the text of that
at IANA's discretion.</t> note may be changed in the future at IANA's discretion.</t>
<!-- IANA: The above would benefit from a conversation <t> IANA's attention is called to the introduction, in
between IANA and the authors at an appropriate time --> <xref target="CodePointReview" format="default"/>, of a t
<t> IANA's attention is called to the introduction, in emporary "under
<xref target="CodePointReview"/>, of a temporary "under
review" category to the PVALID, DISALLOWED, etc., entries review" category to the PVALID, DISALLOWED, etc., entries
in the tables.</t> in the tables.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>Application of the procedures described in this document and <t>Applying the procedures described in this document and
understanding of the clarifications it provides should reduce understanding of the clarifications it provides should reduce
confusion about IDNA requirements. Because past confusion confusion about IDNA requirements. Because past confusion
has provided opportunities for bad behavior, the effect of has provided opportunities for bad behavior, the effect of
these changes should improve Internet security to at least these changes should improve Internet security to at least
some small extent. </t> some small extent. </t>
<t> Because of the preference to keep the derived property <t> Because of the preference to keep the derived property
value stable (as specified in RFC 5892 and value stable (as specified in RFC 5892 and
discussed in <xref target="IDNA-Assumptions"/>), the discussed in <xref target="IDNA-Assumptions" format="default"/>), the
algorithm used to calculate those derived properties does algorithm used to calculate those derived properties does
change as explained in <xref target="ReviewModel"/>. If change as explained in <xref target="ReviewModel" format="default"/>. I f
these changes are not taken into account, the derived these changes are not taken into account, the derived
property value will change and the implications might have property value will change, and the implications might have
negative consequences, in some cases with security negative consequences, in some cases with security
implications. For example, changes in the calculated derived implications. For example, changes in the calculated derived
property value for a code point from either DISALLOWED to property value for a code point from either DISALLOWED to
PVALID or from PVALID to DISALLOWED can cause changes in PVALID or from PVALID to DISALLOWED can cause changes in
label interpretation that would be visible and confusing to label interpretation that would be visible and confusing to
end users and might enable attacks. </t> end users and might enable attacks. </t>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<displayreference target="I-D.klensin-idna-5892upd-unicode70" to="IDNA-Unico
de7"/>
<displayreference target="I-D.faltstrom-unicode12" to="IDNA-Unicode12"/>
<displayreference target="I-D.faltstrom-unicode11" to="IDNA-Unicode11"/>
<displayreference target="I-D.klensin-idna-rfc5891bis" to="RegRestr"/>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<references title="Normative References"> <reference anchor="IANA-IDNA-Tables" target="https://www.iana.org/assign
ments/idna-tables">
&rfc5892; <front>
&rfc8126; <title>IDNA Rules and Derived Property Values</title>
<reference anchor="Unicode"
target="http://www.unicode.org/versions/latest/">
<front>
<title> The Unicode Standard (Current Version)</title>
<author>
<organization> The Unicode Consortium</organization>
<address/>
</author>
<date year="2019"/>
</front>
<annotation> The link given will always access the current
version of the Unicode Standard, independent of its version
number or date.</annotation>
</reference>
<reference anchor="Unicode-properties"
target="https://www.unicode.org/versions/Unicode11.0.0/">
<front>
<title> The Unicode Standard Version 11.0</title>
<author> <author>
<organization> The Unicode Consortium</organization> <organization>IANA</organization>
<address/>
</author> </author>
<date year="2018"/> </front>
</front> </reference>
<annotation> Section 3.5.</annotation>
</reference>
<reference anchor="IANA-IDNA-Tables" <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
target="https://www.iana.org/assignments/idna-tables-11.0.0/idna-tabl C.5892.xml"/>
es-11.0.0.xhtml">
<front>
<title>IDNA Parameters</title>
<author>
<organization>Internet Assigned Numbers Authority
(IDNA)</organization>
</author>
<date year="2019" day="31" month="March"/>
</front>
<annotation> This documents make changes to this registry and
a way that could change the title, the URL, or both. This
citation is to be version published on 2019-03-31. It may
be appropriate to supply a citation to the finished
version when this document is published. </annotation>
</reference>
<reference anchor="RFC5892a" <reference anchor="RFC5892a" target="https://www.rfc-editor.org/rfc/rfc5892
target="http://www.rfc-editor.org/rfc/rfc5892.txt"> .txt">
<front> <front>
<title>The Unicode Code Points and <title>The Unicode Code Points and
Internationalized Domain Names for Applications (IDNA)</title> Internationalized Domain Names for Applications (IDNA)</title>
<author initials="P." surname="Faltstrom" role="editor"> <author initials="P." surname="Faltstrom" role="editor">
<organization/> <organization/>
<address/> <address/>
</author> </author>
<date year="2010" month="August" /> <date year="2010" month="August" />
</front> </front>
<seriesInfo name="RFC" value="5892"/> <seriesInfo name="RFC" value="5892"/>
<annotation> Section 2.7 </annotation> <refcontent>Section 2.7</refcontent>
</reference>
<reference anchor="RFC5892Erratum"
target="http://www.rfc-editor.org/errata_search.php?rfc=5892">
<front>
<title>RFC5892, "The Unicode Code Points and
Internationalized Domain Names for Applications (IDNA)",
August 2010, Errata ID: 3312</title>
<author>
<organization/>
<address/>
</author>
<date year="2012" month="August" day="9" />
</front>
<seriesInfo name="Errata ID" value="3312"/>
</reference> </reference>
</references> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8126.xml"/>
<references title="Informative References">
&rfc3454;
&rfc3490;
&rfc3491;
&rfc4690;
&rfc5890;
&rfc6452;
&rfc5894;
&rfc1766;
&rfc3282;
&rfc3629;
&rfc5646;
<reference anchor="IDNA-Unicode12"
target="https://datatracker.ietf.org/doc/draft-faltstrom-unicode12/"
>
<front>
<title>IDNA2008 and Unicode 12.0.0</title>
<author initials="P." surname="Faltstrom">
<organization></organization>
<address/>
</author>
<date year="2019" month="March" day="11" />
</front>
<annotation> This document is in the RFC Editor queue at of
2019-06-09. Update to RFC reference if/when
appropriate.</annotation>
</reference>
<reference anchor="ID.draft-faltstrom-unicode11" <reference anchor="Unicode" target="http://www.unicode.org/versions/late
target="https://datatracker.ietf.org/doc/draft-faltstrom-unicode11/" st/">
> <front>
<front> <title>The Unicode Standard (Current Version)</title>
<title>IDNA2008 and Unicode 11.0.0</title> <author>
<author initials="P." surname="Faltstrom"> <organization>The Unicode Consortium</organization>
<organization></organization> </author>
<address/> </front>
</author> <annotation>The link given will always access the current
<date year="2019" month="March" day="11" /> version of the Unicode Standard, independent of its version
</front> number or date.</annotation>
</reference> </reference>
<reference anchor="IAB-Unicode7-2015" <reference anchor="Unicode-properties" target="https://www.unicode.org/v
target="https://www.iab.org/documents/correspondence-reports-documents/2 ersions/Unicode11.0.0/">
015-2/iab-statement-on-identifiers-and-unicode-7-0-0/"> <front>
<front> <title>The Unicode Standard Version 11.0</title>
<title> IAB Statement on Identifiers and Unicode 7.0.0</title> <author>
<author> <organization>The Unicode Consortium</organization>
<organization>Internet Architecture Board (IAB)</organization> </author>
<address/> <date year="2018"/>
</author> </front>
<date year="2015" month="February" day="11" /> <refcontent>Section 3.5</refcontent>
</front> </reference>
</reference> </references>
<references>
<name>Informative References</name>
<reference anchor="Err3312" quote-title="false" target="https://www.rfc-
editor.org/errata/eid3312">
<front>
<title>Erratum ID 3312</title>
<author>
<organization>RFC Errata</organization>
</author>
</front>
<refcontent>RFC 5892</refcontent>
</reference>
<reference anchor="IAB-Unicode-2018" <reference anchor="IAB-Unicode-2018" target="https://www.iab.org/documen
target="https://www.iab.org/documents/correspondence-reports-documents/2 ts/correspondence-reports-documents/2018-2/iab-statement-on-identifiers-and-unic
018-2/iab-statement-on-identifiers-and-unicode/"> ode/">
<front> <front>
<title> IAB Statement on Identifiers and Unicode</title> <title>IAB Statement on Identifiers and Unicode</title>
<author> <author>
<organization>Internet Architecture Board (IAB)</organization> <organization>Internet Architecture Board (IAB)</organization>
<address/> </author>
</author> <date year="2018" month="March" day="15"/>
<date year="2018" month="March" day="15" /> </front>
</front> </reference>
</reference>
<reference anchor="IDNA-Unicode7" <reference anchor="IAB-Unicode7-2015" target="https://www.iab.org/docume
target="https://datatracker.ietf.org/doc/draft-klensin-idna-5892upd-un nts/correspondence-reports-documents/2015-2/iab-statement-on-identifiers-and-uni
icode70/03/"> code-7-0-0/">
<front> <front>
<title>IDNA Update for Unicode 7.0.0</title> <title>IAB Statement on Identifiers and Unicode 7.0.0</title>
<author surname="Klensin" initials="J."> <author>
<organization/> </author> <organization>Internet Architecture Board (IAB)</organization>
<author surname="Falstrom" initials="P."> </author>
<organization/> </author> <date year="2015" month="February" day="11"/>
<date year="2015" month="January" day="6"/> </front>
</front> </reference>
<annotation> Note that this is an historical reference to a
superseded document. There is nothing "in progress" about
it.</annotation>
</reference>
<reference anchor="RegRestr" <reference anchor="ICANN-LGR-SLA" target="https://www.icann.org/public-c
target="https://datatracker.ietf.org/doc/draft-klensin-idna-rfc5891b omments/proposed-iana-sla-lgr-idn-tables-2019-06-10-en">
is/">
<front> <front>
<title>Internationalized Domain Names in Applications <title>Proposed IANA SLAs for Publishing LGRs/IDN Tables
(IDNA): Registry Restrictions and Recommendations </title>
</title> <author>
<author surname="Klensin" initials="J."> <organization>Internet Corporation for Assigned Names
<organization/> </author>
<author surname="Freytag" initials="A.">
<organization/> </author>
<date year="2019" month="July" day="6"/>
</front>
</reference>
<reference anchor="ICANN-LGR-SLA"
target="https://www.icann.org/public-comments/proposed-iana-sla-lgr-
idn-tables-2019-06-10-en">
<front>
<title> Proposed IANA SLAs for Publishing LGRs/IDN Tables
</title>
<author>
<organization> Internet Corporation for Assigned Names
and Numbers (ICANN)</organization> and Numbers (ICANN)</organization>
</author> </author>
<date year="2019" month="June" day="10"/> <date year="2019" month="June" day="10"/>
</front> </front>
<annotation>Captured 2019-06-12. In public comment until </reference>
2019-07-26. </annotation> <xi:include href="https://www.rfc-editor.org/refs/bibxml3/reference.I-D.
</reference> klensin-idna-5892upd-unicode70.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml3/reference.I-D.
</references> faltstrom-unicode11.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml3/reference.I-D.
<!-- Sections below here become Appendices. --> faltstrom-unicode12.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml3/reference.I-D.
<section title="Summary of Changes to RFC 5892"> klensin-idna-rfc5891bis.xml"/>
<t> Other than the editorial correction specified in <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<xref target="ApplyErratum"/> all of the changes in this FC.1766.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3282.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3454.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3490.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3491.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3629.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4690.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5646.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5890.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5894.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6452.xml"/>
</references>
</references>
<section numbered="true" toc="default">
<name>Summary of Changes to RFC 5892</name>
<t> Other than the editorial correction specified in
<xref target="ApplyErratum" format="default"/>, all of the chan
ges in this
document are concerned with the reviews for new versions of document are concerned with the reviews for new versions of
Unicode and with the IANA Considerations in Section 5, Unicode and with the IANA Considerations in
particularly Section 5.1, of RFC 5982. Whether the changes <xref target="RFC5892" section="5" sectionFormat="of" format="
default"/>,
particularly <xref target="RFC5892" section="5.1" sectionFormat
="of" format="default"/>. Whether the changes
are substantive or merely clarifications may be somewhat in are substantive or merely clarifications may be somewhat in
the eye of the beholder so the list below should not be the eye of the beholder, so the list below should not be
assumed to be comprehensive. At a very high level, this docume nt assumed to be comprehensive. At a very high level, this docume nt
clarifies that two types of review were intended and clarifies that two types of review were intended and
separates them for clarity and restores the original (but so separates them for clarity. This document also restores the ori ginal (but so
far unobserved) default for actions when code point derived far unobserved) default for actions when code point derived
properties change. For this reason, this document properties change. For this reason, this document
effectively provides a replacement for Section 5.1 of RFC effectively replaces <xref target="RFC5892" section="5.1" secti
5892 and adds or changes some material needed to have the onFormat="of" format="default"/>
replacement be clear or make better sense. </t> and adds or changes some text so that the
<t> Changes or clarifications that may be considered important replacement makes better sense. </t>
<t> Changes or clarifications that may be considered important
include: include:
<list style="symbols"> </t>
<t>Separated the new Unicode version review into two <ul spacing="normal">
<li>Separated the new Unicode version review into two
explicit parts and provided for different review explicit parts and provided for different review
methods and, potentially, asynchronous outcomes. methods and, potentially, asynchronous outcomes.
</t> </li>
<t> Specified a review team, not a single expert, for th <li> Specified a DE team, not a single designated expert, for the
e code point review.</li>
code point review.</t> <li> Eliminated the de facto requirement for the (formerly
<t> Eliminated the de facto requirement for the (formerl single) designated expert to be the same person a
y s the
single) Designated Expert to be the same person a IAB's liaison to the Unicode Consortium, but call
s the ed out
IAB's Liaison to the Unicode Consortium but calle the importance of coordination.</li>
d out <li>
the importance of coordination.</t> Created the "Status" field in the IANA tables to inform the
<t> Created an explicit provision for an "under review" community about specific potentially problematic code points.
entry in the IANA tables so that, if there is eve This change creates the ability to add information about such
r code points before IETF review is completed instead of having the review
again a need to tell the community to wait until process hold up the use of the new Unicode version.
the </li>
IETF sorts things out, that will be about selecte <li> In part because Unicode is now on a regular one-year
d
potentially problematic code points and not whole
Unicode versions.</t>
<t> In part because Unicode is now on a regular one-year
cycle rather than producing major and minor versi ons cycle rather than producing major and minor versi ons
as needed, to avoid overloading the IETF's i18n as needed, to avoid overloading the IETF's intern ationalization
resources, and to avoid generating and storing IA NA resources, and to avoid generating and storing IA NA
tables for trivial changes (e.g., the single new code tables for trivial changes (e.g., the single new code
point in Unicode 12.1), the review procedure is point in Unicode 12.1), the review procedure is
applied only to major versions of Unicode unless applied only to major versions of Unicode unless
exceptional circumstances arise and are identifie exceptional circumstances arise and are identifie
d.</t> d.</li>
</list></t> </ul>
</section> </section>
<section anchor="ExpertRationale" numbered="true" toc="default">
<section title="Background and Rationale for Expert Review Procedure f <name>Background and Rationale for Expert Review Procedure for New Code Po
or New Code Point Analysis" int Analysis</name>
anchor="ExpertRationale"> <t> The expert review procedure for new code point analysis described
<t> The Expert Review for New Code Point Analysis provided in <xref target="CodePointReview" format="default"/> is
for above is somewhat unusual compared to the examples somewhat unusual compared to the examples
presented in the Guidelines for Writing presented in the Guidelines for Writing
IANA Considerations <xref target="RFC8126"/>. This IANA Considerations <xref target="RFC8126" format="defau
appendix provides an explanation of that choice and the lt"/>. This
appendix explains that choice and provides the
background for it.</t> background for it.</t>
<t>Development of specifications to support use of languages <t>Development of specifications to support use of languages
and writing systems other than English (and Latin Script and writing systems other than English (and Latin script
) )
-- so-called "internationalization" or "i18n" -- -- so-called "internationalization" or "i18n" --
has always been problematic in the IETF, especially when has always been problematic in the IETF, especially when
requirements go beyond simple coding of characters (e.g. , requirements go beyond simple coding of characters (e.g. ,
<xref target="RFC3629">RFC 3629</xref>) or simple <xref target="RFC3629" format="default">RFC 3629</xref>) or simple
identification of languages (e.g., identification of languages (e.g.,
<xref target="RFC3282">RFC 3282</xref> and the earlier <xref target="RFC3282" format="default">RFC 3282</xref>
<xref target="RFC1766">RFC 1766</xref>). A good deal of and the earlier
<xref target="RFC1766" format="default">RFC 1766</xref>)
. A good deal of
specialized knowledge is required, knowledge that comes specialized knowledge is required, knowledge that comes
from multiple fields and that requires multiple from multiple fields and that requires multiple
perspectives. The work is not obviously more complex perspectives. The work is not obviously more complex
than routing, especially if one assumes that routing wor k than routing, especially if one assumes that routing wor k
requires a solid foundation in graph theory or network requires a solid foundation in graph theory or network
optimization, or than security and cryptography, but optimization, or than security and cryptography, but
people working in those areas are drawn to the IETF and people working in those areas are drawn to the IETF and
people from the fields that bear on internationalization people from the fields that bear on internationalization
typically are not.</t> typically are not.</t>
<t> One result is that we have several times thought we <t> As a result, we have often thought we
understood a problem, generated a specification or set o f understood a problem, generated a specification or set o f
specifications, and then been surprised when specifications, but then have been surprised by
unanticipated (by the IETF) issues arose and we needed t unanticipated (by the IETF) issues. We then needed to
o tune and often revise our specification.
go back and at least tune and often revise.
The language tag work that The language tag work that
started with RFC 1766 is a good example of this: broader started with RFC 1766 is a good example of this: broader
considerations and requirements led to later work and a considerations and requirements led to later work and a
much more complex and finer-grained system much more complex and finer-grained system
<xref target="RFC5646"/></t> <xref target="RFC5646" format="default"/>.</t>
<t> Work on IDNs further increased the difficulties because <t> Work on IDNs further increased the difficulties because
many of the decisions that led to the current version of many of the decisions that led to the current version of
IDNA require understanding the DNS and its constraints IDNA require understanding the DNS, its constraints,
and, to at least some extent, the commercial market in and, to at least some extent, the commercial market of
domain names including various ICANN efforts.</t> domain names, including various ICANN efforts.</t>
<t> The net result of these factors is that it is extremely <t> The net result of these factors is that it is extremely
unlikely that the IESG will ever find an Expert Reviewer unlikely that the IESG will ever find a designated exper
t
whose knowledge and understanding will include everythin g whose knowledge and understanding will include everythin g
that is required. </t> that is required. </t>
<t> Consequently, <xref target="IANA"/> and other discussions <t> Consequently, <xref target="IANA" format="default"/>
in this document specify a review team with the and other discussions in this document
expectation that the members of the team will, together, specify a DE team that is expected to have the broad perspective,
have have a broad enough perspective, expertise, and access to information and community in order to
collection of expertise, and access to information and review new Unicode versions and to make consensus recommendations
community to consult, so as to be able to do a review an that will serve the Internet well. While we anticipate that the
d team will have one or more leaders, the structure of the team differs
make consensus recommendations that will serve the from the suggestions given in <xref target="RFC8126"
Internet well. While we anticipate that the team will section="5.2" sectionFormat="of">the Guidelines
have one or more leaders, this differs from the for Writing IANA Considerations</xref>
suggestions in Section 5.2 of the Guidelines for Writing since neither the team's formation nor its consultation is left to
IANA Considerations <xref target="RFC8126"/> by not the discretion of the designated expert, nor is the designated
leaving whether or not a team exists or how it is expert solely accountable to the community. A team that contains
consulted to the discretion of the designated expert nor multiple perspectives is required, the team members are accountable
is the expert solely accountable to the community. A as a group, and any nontrivial recommendations require team consensus.
team that contains multiple perspectives is required, th This also differs from the common practice in the IETF of
e "review teams" from which a single member is selected to
team members are accountable as a group, and any perform a review: the principle for these reviews is team effort.</t>
non-trivial recommendations require team consensus. Thi </section>
s
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 tea
m
effort. </t>
</section>
<section title="Change Log" anchor="ChangeLog">
<t>RFC Editor: Please remove this appendix before
publication.</t>
<section title="Changes from version -00 (2019-06-12) to -01">
<t><list style="symbols">
<t> Added a note about the relationship to
draft-klensin-idna-rfc5891bis. </t>
<t> Adjusted references per discussion with RFC
Editor.</t>
<t> Minor editorial corrections and improvements.</t>
</list></t>
</section>
<section title="Changes from version -01 (2019-07-06) to -02">
<t><list style="symbols">
<t> Removed an unnecessary reference and a duplicate
one.</t>
</list></t>
</section>
<section title="Changes from version -02 (2019-07-22) to -03">
<t><list style="symbols">
<t> Addition of text to Section 3 to clarify IESG
responsibilities.</t>
<t> Very small editorial changes in response to AD
review. </t>
</list></t>
</section>
<section title="Changes from version -03 (2019-08-29) to -04">
<t><list style="symbols">
<t> Added <xref target="ExpertRationale"/> to describe
the reasoning and details of the review team for
New
Code Point Analysis and slightly updated the IANA
Considerations section to point to it.</t>
<t> Corrections for editorial problems identified after
IETF Last Call. </t>
</list></t>
</section>
<!-- RFC Editor: since this Change Log section will be deleted
entirely, I didn't bother producing the Section covering -04 to
-05 changes -->
<section anchor="Acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t> 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 <contact fullname="Joel Halpern"/> a
nd
text suggestions from <contact fullname="Barry Leiba"/> resulted
in some
clarifications.</t>
<t> Thanks to <contact fullname="Christopher Wood"/> for catching some edi
torial
errors that persisted until rather late in the document's
life cycle and to <contact fullname="Benjamin Kaduk"/> for catch
ing 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.</t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 114 change blocks. 
715 lines changed or deleted 495 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/