< draft-klensin-idna-rfc5891bis-00.txt   draft-klensin-idna-rfc5891bis-01.txt >
Network Working Group J. Klensin Network Working Group J. Klensin
Internet-Draft Internet-Draft
Updates: 5890, 5891 (if approved) A. Freytag Updates: 5890, 5891, 5894 (if approved) A. Freytag
Intended status: Standards Track ASMUS, Inc. Intended status: Standards Track ASMUS, Inc.
Expires: September 12, 2017 March 11, 2017 Expires: March 16, 2018 September 12, 2017
Internationalized Domain Names in Applications (IDNA): Registry Internationalized Domain Names in Applications (IDNA): Registry
Restrictions and Recommendations Restrictions and Recommendations
draft-klensin-idna-rfc5891bis-00.txt draft-klensin-idna-rfc5891bis-01
Abstract Abstract
The IDNA specifications for internationalized domain names combine The IDNA specifications for internationalized domain names combine
rules that determine the labels that are allowed in the DNS without rules that determine the labels that are allowed in the DNS without
violating the protocol itself and an assignment of responsibility, violating the protocol itself and an assignment of responsibility,
consistent with earlier specifications, for determining the labels consistent with earlier specifications, for determining the labels
that are allowed in particular zones. Conformance to IDNA by that are allowed in particular zones. Conformance to IDNA by
registries and other implementations requires both parts. Experience registries and other implementations requires both parts. Experience
strongly suggests that the language describing those responsibility strongly suggests that the language describing those responsibilities
was insufficiently clear to promote safe and interoperable use of the was insufficiently clear to promote safe and interoperable use of the
specifications and that more details and some specific examples would specifications and that more details and some specific examples would
have been helpful. This specification updates the earlier ones to have been helpful. Without making any substantive changes to IDNA,
provide that guidance and to correct some technical errors in the this specification updates two of the core IDNA documents (RFC 5980
descriptions. It does not alter the protocols and rules themselves and 5891) and the IDNA explanatory document (RFC 5894) to provide
in any way. that guidance and to correct some technical errors in the
descriptions.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2017. This Internet-Draft will expire on March 16, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Registry Restrictions in IDNA2008 . . . . . . . . . . . . . . 3 2. Registry Restrictions in IDNA2008 . . . . . . . . . . . . . . 3
3. Progressive Subsets of Allowed Characters . . . . . . . . . . 4 3. Progressive Subsets of Allowed Characters . . . . . . . . . . 4
4. Other corrections and updates . . . . . . . . . . . . . . . . 7 4. Other corrections and updates . . . . . . . . . . . . . . . . 6
4.1. Updates to RFC 5890 . . . . . . . . . . . . . . . . . . . 7 4.1. Updates to RFC 5890 . . . . . . . . . . . . . . . . . . . 7
4.2. Updates to RFC 5891 . . . . . . . . . . . . . . . . . . . 7 4.2. Updates to RFC 5891 . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Related Discussions . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12
A.1. Changes from version -00 (2017-03-11) to -01 . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Parts of the specifications for Internationalized Domain Names in Parts of the specifications for Internationalized Domain Names in
Applications (IDNA) [RFC5890] [RFC5891] [RFC5894] (collectively Applications (IDNA) [RFC5890] [RFC5891] [RFC5894] (collectively
known, along with RFC 5892 [RFC5892], RFC 5893 [RFC5893] and updates known, along with RFC 5892 [RFC5892], RFC 5893 [RFC5893] and updates
to them, as "IDNA2008" (or just "IDNA") impose a requirement that to them, as "IDNA2008" (or just "IDNA") impose a requirement that
domain name system (DNS) registries restrict the characters they domain name system (DNS) registries restrict the characters they
allow in domain name labels (see Section 2 below), and the contents allow in domain name labels (see Section 2 below), and the contents
and structure of those labels. That requirement and restriction are and structure of those labels. That requirement and restriction are
skipping to change at page 3, line 40 skipping to change at page 3, line 42
the DNS. It also makes a specific recommendation for character the DNS. It also makes a specific recommendation for character
repertoire subsetting intermediate between the code points allowed by repertoire subsetting intermediate between the code points allowed by
RFC 5891 and 5892 and those allowed by individual registries. It RFC 5891 and 5892 and those allowed by individual registries. It
does not alter the basic IDNA2008 protocols and rules themselves in does not alter the basic IDNA2008 protocols and rules themselves in
any way. any way.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
[[NOTE IN DRAFT: While the co-authors have gone through several
iterations of this I-D and discussed some sectons of it with others,
it is still a very preliminary version. In particular, the specific
material in Section 4 has not yet been inserted.]]
2. Registry Restrictions in IDNA2008 2. Registry Restrictions in IDNA2008
As mentioned above, IDNA2008 specifies that the registries for each As mentioned above, IDNA2008 specifies that the registries for each
zone in the DNS that supports IDN labels are required to develop and zone in the DNS that supports IDN labels are required to develop and
apply their own rules to restrict the allowable labels, including apply their own rules to restrict the allowable labels, including
limiting characters they allow to be used in labels in that zone. limiting characters they allow to be used in labels in that zone.
The chosen list MUST BE smaller than the collection of code points The chosen list MUST BE smaller than the collection of code points
specified as "PVALID", "CONTEXTJ", and "CONTEXTO" by the rules specified as "PVALID", "CONTEXTJ", and "CONTEXTO" by the rules
established by the protocols themselves. The latter two categories, established by the protocols themselves. The latter two categories,
and labels containing any characters that are normally part of a and labels containing any characters that are normally part of a
skipping to change at page 4, line 44 skipping to change at page 4, line 42
distinguish characters in different scripts around the world and distinguish characters in different scripts around the world and
under different circumstances. under different circumstances.
3. Progressive Subsets of Allowed Characters 3. Progressive Subsets of Allowed Characters
The algorithm and rules of RFC 5891 and 5892 set an absolute upper The algorithm and rules of RFC 5891 and 5892 set an absolute upper
bound on the code points that can be used in domain name labels; bound on the code points that can be used in domain name labels;
registries MUST NOT include code points unless they are allowed by registries MUST NOT include code points unless they are allowed by
those rules. Each registry that intends to allow IDN registrations those rules. Each registry that intends to allow IDN registrations
MUST then determine which code points will be allowed by that MUST then determine which code points will be allowed by that
registry and SHOULD consider additional rules, including contextual registry. It SHOULD also consider additional rules, including
and whole label restrictions that provide further protection for contextual and whole label restrictions that provide further
registrants and users. For example, the widely-used principle that protection for registrants and users. For example, the widely-used
bars labels containing characters from more than one script is not an principle that bars labels containing characters from more than one
IDNA2008 requirement. It has been adopted by many registries but, as script is not an IDNA2008 requirement. It has been adopted by many
Section 4.4 of RFC 5890 indicates, there may be circumstances in registries but, as Section 4.4 of RFC 5890 indicates, there may be
which is it not required or appropriate. circumstances in which is it not required or appropriate.
In formulating their own rules, registries SHOULD normally consult In formulating their own rules, registries SHOULD normally consult
carefully-developed consensus recommendations about global maximum carefully-developed consensus recommendations about global maximum
repertoires to be used such as the ICANN Maximal Starting Repertoire repertoires to be used such as the ICANN Maximal Starting Repertoire
2 (MSR-2) for the Development of Label Generation Rules for the Root 2 (MSR-2) for the Development of Label Generation Rules for the Root
Zone [ICANN-MSR2] (or its successor documents). Additional Zone [ICANN-MSR2] (or its successor documents). Additional
recommendations of similar quality about particular scripts or recommendations of similar quality about particular scripts or
languages exist, including, but not limited to, the RFCs for Cyrillic languages exist, including, but not limited to, the RFCs for Cyrillic
[RFC5992] or Arabic Language [RFC5564] or script-based repertoires [RFC5992] or Arabic Language [RFC5564] or script-based repertoires
from the approved ICANN Root Zone Label Generation Rules (LGR-1) from the approved ICANN Root Zone Label Generation Rules (LGR-1)
[ICANN-LGR1] (or its successor documents). [ICANN-LGR1] (or its successor documents).
It is the responsibility of the registry to determine which, if any, It is the responsibility of the registry to determine which, if any,
of those recommendations are applicable and to further subset or of those recommendations are applicable and to further subset or
extend them as needed. For example, several of the recommendations extend them as needed. For example, several of the recommendations
are designed for the root zone and therefore exclude digits and are designed for the root zone and therefore exclude digits and
U+002D HYPHEN-MINUS, a restriction not generally appropriate for U+002D HYPHEN-MINUS; this restriction is not generally appropriate
other zones. On the other hand, some zones may be designed to not for other zones. On the other hand, some zones may be designed to
cater for all users of a given script, but perhaps only for the needs not cater for all users of a given script, but perhaps only for the
of selected languages, in which case a more selective repertoire may needs of selected languages, in which case a more selective
be appropriate. repertoire may be appropriate.
In making these determinations, a registry SHOULD follow the IAB In making these determinations, a registry SHOULD follow the IAB
guidance in RFC 6912 [RFC6912]. Those guidelines include a number of guidance in RFC 6912 [RFC6912]. Those guidelines include a number of
principles for use in making decisions about allowable code points. principles for use in making decisions about allowable code points.
In addition, that document notes that the closer a particular zone is In addition, that document notes that the closer a particular zone is
to the root, the more restrictive the space of permitted labels to the root, the more restrictive the space of permitted labels
should be. RFC 5894 provides some suggestions for any registry that should be. RFC 5894 provides some suggestions for any registry that
may decide to reduce opportunities for confusion or attacks by may decide to reduce opportunities for confusion or attacks by
constructing policies that disallow characters used in historic constructing policies that disallow characters used in historic
writing systems (whether these be archaic scripts or extensions of writing systems (whether these be archaic scripts or extensions of
skipping to change at page 7, line 20 skipping to change at page 7, line 14
community, the relevant corrections for RFC 5890 and 5891 are noted community, the relevant corrections for RFC 5890 and 5891 are noted
below and update the corresponding documents. There are no errata below and update the corresponding documents. There are no errata
for RFC 5893 or 5894 as of the date this document was published. for RFC 5893 or 5894 as of the date this document was published.
Because further updates to RFC 5892 would require addressing other Because further updates to RFC 5892 would require addressing other
pending issues, the outstanding erratum for that document is not pending issues, the outstanding erratum for that document is not
considered here. For consistency with the original documents, considered here. For consistency with the original documents,
references to Unicode 5.0 are preserved. references to Unicode 5.0 are preserved.
4.1. Updates to RFC 5890 4.1. Updates to RFC 5890
Errata ID 4695: The maximum length mess The outstanding errata against RFC 5890 (Errata ID 4695, 4696, 4823,
... to be supplied ... and 4824 [RFC-Editor-5890Errata]) are all associated with the same
issue, the number of Unicode characters that can be associated with a
maximum-length (63 octet) A-label. In retrospect and contrary to
some of the suggestions in the errata, that value should not be
expressed in octets because RFC 5890 and the other IDNA 2008
documents are otherwise careful to not specify Unicode encoding forms
but, instead, work exclusively with Unicode code points.
Consequently the relevant material in RFC 5890 should be corrected as
follows:
Errata ID 4824: More comments about length Section 2.3.2.1
Note: "Hold for doc update".
... to be supplied ...
Errata ID 4823: More comments about length Old: expansion of the A-label form to a U-label may produce
Note: "Hold for doc update". strings that are much longer than the normal 63 octet DNS limit
... to be supplied ... (potentially up to 252 characters).
New: expansion of the A-label form to a U-label may produce
strings that are much longer than the normal 63 octet DNS limit
(See Section 4.2).
Comment: If the length limit is going to be a source of confusion
or careful calculations, it should appear in only one place.
Section 4.2
Old: Because A-labels (the form actually used in the DNS) are
potentially much more compressed than UTF-8 (and UTF-8 is, in
general, more compressed that UTF-16 or UTF-32), U-labels that
obey all of the relevant symmetry (and other) constraints of
these documents may be quite a bit longer, potentially up to
252 characters (Unicode code points).
New: A-labels (the form actually used in the DNS) and the
Punycode algorithm used as part of the process to produce them
[RFC3492] are strings that are potentially much more compressed
than any standard Unicode Encoding Form. [[CREF1: Do we need a
reference for this here??]] A 63 octet A-label cannot
represent more than 58 Unicode code points (four octet overhead
and the requirement that at least one character lie outside the
ASCII range) but implementations allocating buffer space for
the conversion should allow significantly more space depending
on the encoding form they are using.
4.2. Updates to RFC 5891 4.2. Updates to RFC 5891
Errata ID 3969: Improve reference for combining marks Errata ID 3969: Improve reference for combining marks There is only
Note: "Hold for doc update". one erratum for RFC 5891, Errata ID 3969 [RFC5891Erratum].
Combining marks are explained in the cited section, but not, as
the text indicates, exactly defined.
5. Security Considerations Old: The Unicode string MUST NOT begin with a combining mark or
combining character (see The Unicode Standard, Section 2.11
[Unicode] for an exact definition).
New: The Unicode string MUST NOT begin with a combining mark or
combining character (see The Unicode Standard, Section 2.11
[Unicode] for an explanation and Section 3.6, definition D52)
for an exact definition).
Comment: When RFC 5891 is actually updated, the references in the
text should be updated to the current version of Unicode and
the section numbers checked.
5. Related Discussions
This document is one of a series of measures that have been suggested
to address IDNA issues raised in other documents, including
mechanisms for dealing with combining sequences and single-code point
characters with the same appearance that normalization neither
combines nor decomposes as IDNA2008 assumed [IDNA-Unicode], including
the IAB response to that issue [IAB-2015], and to take a higher-level
view of issues, demands, and proposals for new uses of the DNS.
Those documents also include a discussion of issues with IDNA and
character graphemes for which abstractions exist in Unicode in
precomposed form but that can be generated from combining sequences
and a suggested registry of code points known to be problematic
[Freytag-troublesome]. The discussion of combining sequences and
non-decomposing characters is intended to lay the foundation for an
actual update to the IDNA code points document [RFC5892]. Such an
update will presumably also address the existing errata against that
document.
6. Security Considerations
As discussed in IAB recommendations about internationalized domain As discussed in IAB recommendations about internationalized domain
names [RFC4690], [RFC6912], and elsewhere, poor choices of strings names [RFC4690], [RFC6912], and elsewhere, poor choices of strings
for DNS labels can lead to opportunities for attacks, user confusion, for DNS labels can lead to opportunities for attacks, user confusion,
and other issues less directly related to security. This document and other issues less directly related to security. This document
clarifies the importance of registries carefully establishing design clarifies the importance of registries carefully establishing design
policies for the labels they will allow and that having such policies policies for the labels they will allow and that having such policies
and taking responsibility for them is a requirement, not an option. and taking responsibility for them is a requirement, not an option.
If that clarification is useful in practice, the result should be an If that clarification is useful in practice, the result should be an
improvement in security. improvement in security.
6. Acknowledgements 7. Acknowledgments
... placeholder ... Many thanks to Patrik Faltstrom who provided an important review on
the initial version.
7. IANA Considerations 8. IANA Considerations
[[CREF1: RFC Editor: Please remove this section before publication.]] [[CREF2: RFC Editor: Please remove this section before publication.]]
This memo includes no requests to or actions for IANA. In This memo includes no requests to or actions for IANA. In
particular, it does not contain any provisions that would alter any particular, it does not contain any provisions that would alter any
IDNA-related registries or tables. IDNA-related registries or tables.
8. References 9. References
8.1. Normative References 9.1. Normative References
[ICANN-LGR1] [ICANN-LGR1]
ICANN, "Root Zone Label Generation Rules (LGR-1)", June ICANN, "Root Zone Label Generation Rules (LGR-1)", June
2015, <https://www.icann.org/resources/pages/root-zone- 2015, <https://www.icann.org/resources/pages/
lgr-2015-06-21-en>. root-zone-lgr-2015-06-21-en>.
[ICANN-MSR2] [ICANN-MSR2]
ICANN, "Maximal Starting Repertoire Version 2 (MSR-2) for ICANN, "Maximal Starting Repertoire Version 2 (MSR-2) for
the Development of Label Generation Rules for the Root the Development of Label Generation Rules for the Root
Zone", April 2015, <https://www.icann.org/news/ Zone", April 2015,
announcement-2-2015-04-27-en>. <https://www.icann.org/news/announcement-2-2015-04-27-en>.
[RFC1591] Postel, J., "Domain Name System Structure and Delegation", [RFC1591] Postel, J., "Domain Name System Structure and Delegation",
RFC 1591, DOI 10.17487/RFC1591, March 1994, RFC 1591, DOI 10.17487/RFC1591, March 1994,
<http://www.rfc-editor.org/info/rfc1591>. <https://www.rfc-editor.org/info/rfc1591>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010, RFC 5890, DOI 10.17487/RFC5890, August 2010,
<http://www.rfc-editor.org/info/rfc5890>. <https://www.rfc-editor.org/info/rfc5890>.
[RFC5891] Klensin, J., "Internationalized Domain Names in [RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, Applications (IDNA): Protocol", RFC 5891,
DOI 10.17487/RFC5891, August 2010, DOI 10.17487/RFC5891, August 2010,
<http://www.rfc-editor.org/info/rfc5891>. <https://www.rfc-editor.org/info/rfc5891>.
[RFC5892Erratum] [RFC5891Erratum]
"RFC5892, "The Unicode Code Points and Internationalized "RFC 5891, "Internationalized Domain Names in Applications
Domain Names for Applications (IDNA)", August 2010, Errata (IDNA): Protocol"", Errata ID 3969, April 2014,
ID: 3312", Errata ID 3312, August 2012, <http://www.rfc-editor.org/errata_search.php?rfc=5891>.
<http://www.rfc-editor.org/errata_search.php?rfc=5892>.
[RFC5894] Klensin, J., "Internationalized Domain Names for [RFC5894] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Background, Explanation, and Applications (IDNA): Background, Explanation, and
Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010, Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010,
<http://www.rfc-editor.org/info/rfc5894>. <https://www.rfc-editor.org/info/rfc5894>.
8.2. Informative References 9.2. Informative References
[Freytag-troublesome]
Freytag, A., Klensin, J., and A. Sullivan, "Those
Troublesome Characters: A Registry of Unicode Code Points
Needing Special Consideration When Used in Network
Identifiers", June 2017, <draft-freytag-troublesome-
characters-01>.
[IAB-2015]
Internet Architecture Board (IAB), "IAB Statement on
Identifiers and Unicode 7.0.0", February 2015,
<https://www.iab.org/documents/
correspondence-reports-documents/2015-2/
iab-statement-on-identifiers-and-unicode-7-0-0/>.
[IDNA-Unicode]
Klensin, J. and P. Falstrom, "IDNA Update for Unicode
7.0.0", September 2017, <draft-klensin-idna-5892upd-
unicode70-05>.
[LGR-Procedure] [LGR-Procedure]
Internet Corporation for Assigned Names and Numbers Internet Corporation for Assigned Names and Numbers
(ICANN), "Procedure to Develop and Maintain the Label (ICANN), "Procedure to Develop and Maintain the Label
Generation Rules for the Root Zone in Respect of IDNA Generation Rules for the Root Zone in Respect of IDNA
Labels", March 2013, Labels", March 2013,
<https://www.icann.org/en/system/files/files/draft-lgr- <https://www.icann.org/en/system/files/files/
procedure-20mar13-en.pdf>. draft-lgr-procedure-20mar13-en.pdf>.
[RFC-Editor-5890Errata]
RFC Editor, "RFC Errata: RFC 5890, "Internationalized
Domain Names for Applications (IDNA): Definitions and
Document Framework", August 2010", Note to RFC
Editor: Please figure out how you would like this
referenced and make it so., Captured 2017-09-10, 2016,
<https://www.rfc-editor.org/errata_search.php?rfc=5890>.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications
(IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
<https://www.rfc-editor.org/info/rfc3492>.
[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and
Recommendations for Internationalized Domain Names Recommendations for Internationalized Domain Names
(IDNs)", RFC 4690, DOI 10.17487/RFC4690, September 2006, (IDNs)", RFC 4690, DOI 10.17487/RFC4690, September 2006,
<http://www.rfc-editor.org/info/rfc4690>. <https://www.rfc-editor.org/info/rfc4690>.
[RFC4713] Lee, X., Mao, W., Chen, E., Hsu, N., and J. Klensin, [RFC4713] Lee, X., Mao, W., Chen, E., Hsu, N., and J. Klensin,
"Registration and Administration Recommendations for "Registration and Administration Recommendations for
Chinese Domain Names", RFC 4713, DOI 10.17487/RFC4713, Chinese Domain Names", RFC 4713, DOI 10.17487/RFC4713,
October 2006, <http://www.rfc-editor.org/info/rfc4713>. October 2006, <https://www.rfc-editor.org/info/rfc4713>.
[RFC5564] El-Sherbiny, A., Farah, M., Oueichek, I., and A. Al-Zoman, [RFC5564] El-Sherbiny, A., Farah, M., Oueichek, I., and A. Al-Zoman,
"Linguistic Guidelines for the Use of the Arabic Language "Linguistic Guidelines for the Use of the Arabic Language
in Internet Domains", RFC 5564, DOI 10.17487/RFC5564, in Internet Domains", RFC 5564, DOI 10.17487/RFC5564,
February 2010, <http://www.rfc-editor.org/info/rfc5564>. February 2010, <https://www.rfc-editor.org/info/rfc5564>.
[RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and
Internationalized Domain Names for Applications (IDNA)", Internationalized Domain Names for Applications (IDNA)",
RFC 5892, DOI 10.17487/RFC5892, August 2010, RFC 5892, DOI 10.17487/RFC5892, August 2010,
<http://www.rfc-editor.org/info/rfc5892>. <https://www.rfc-editor.org/info/rfc5892>.
[RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts [RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts
for Internationalized Domain Names for Applications for Internationalized Domain Names for Applications
(IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010, (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010,
<http://www.rfc-editor.org/info/rfc5893>. <https://www.rfc-editor.org/info/rfc5893>.
[RFC5992] Sharikov, S., Miloshevic, D., and J. Klensin, [RFC5992] Sharikov, S., Miloshevic, D., and J. Klensin,
"Internationalized Domain Names Registration and "Internationalized Domain Names Registration and
Administration Guidelines for European Languages Using Administration Guidelines for European Languages Using
Cyrillic", RFC 5992, DOI 10.17487/RFC5992, October 2010, Cyrillic", RFC 5992, DOI 10.17487/RFC5992, October 2010,
<http://www.rfc-editor.org/info/rfc5992>. <https://www.rfc-editor.org/info/rfc5992>.
[RFC6452] Faltstrom, P., Ed. and P. Hoffman, Ed., "The Unicode Code [RFC6452] Faltstrom, P., Ed. and P. Hoffman, Ed., "The Unicode Code
Points and Internationalized Domain Names for Applications Points and Internationalized Domain Names for Applications
(IDNA) - Unicode 6.0", RFC 6452, DOI 10.17487/RFC6452, (IDNA) - Unicode 6.0", RFC 6452, DOI 10.17487/RFC6452,
November 2011, <http://www.rfc-editor.org/info/rfc6452>. November 2011, <https://www.rfc-editor.org/info/rfc6452>.
[RFC6912] Sullivan, A., Thaler, D., Klensin, J., and O. Kolkman, [RFC6912] Sullivan, A., Thaler, D., Klensin, J., and O. Kolkman,
"Principles for Unicode Code Point Inclusion in Labels in "Principles for Unicode Code Point Inclusion in Labels in
the DNS", RFC 6912, DOI 10.17487/RFC6912, April 2013, the DNS", RFC 6912, DOI 10.17487/RFC6912, April 2013,
<http://www.rfc-editor.org/info/rfc6912>. <https://www.rfc-editor.org/info/rfc6912>.
Appendix A. Change Log
RFC Editor: Please remove this appendix before publication.
A.1. Changes from version -00 (2017-03-11) to -01
o Added Acknowledgments and adjusted references.
o Filled in Section 4 with updates to respond to errata.
o Added Section 5 to discuss relationships to other documents.
o Modified the Abstract to note specifically updated documents.
o Several small editorial changes and corrections.
Authors' Addresses Authors' Addresses
John C Klensin John C Klensin
1770 Massachusetts Ave, Ste 322 1770 Massachusetts Ave, Ste 322
Cambridge, MA 02140 Cambridge, MA 02140
USA USA
Phone: +1 617 245 1457 Phone: +1 617 245 1457
Email: john-ietf@jck.com Email: john-ietf@jck.com
 End of changes. 42 change blocks. 
79 lines changed or deleted 193 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/