< draft-klensin-idna-rfc5891bis-01.txt   draft-klensin-idna-rfc5891bis-02.txt >
Network Working Group J. Klensin Network Working Group J. Klensin
Internet-Draft Internet-Draft
Updates: 5890, 5891, 5894 (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: March 16, 2018 September 12, 2017 Expires: January 7, 2020 July 6, 2019
Internationalized Domain Names in Applications (IDNA): Registry Internationalized Domain Names in Applications (IDNA): Registry
Restrictions and Recommendations Restrictions and Recommendations
draft-klensin-idna-rfc5891bis-01 draft-klensin-idna-rfc5891bis-02
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 responsibilities 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 discussion of circumstances
have been helpful. Without making any substantive changes to IDNA, would have been helpful. Without making any substantive changes to
this specification updates two of the core IDNA documents (RFC 5980 IDNA, this specification updates two of the core IDNA documents (RFC
and 5891) and the IDNA explanatory document (RFC 5894) to provide 5980 and 5891) and the IDNA explanatory document (RFC 5894) to
that guidance and to correct some technical errors in the provide that guidance and to correct some technical errors in the
descriptions. 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 https://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 March 16, 2018. This Internet-Draft will expire on January 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://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 . . . . . . . . . . . . . . 4
3. Progressive Subsets of Allowed Characters . . . . . . . . . . 4 3. Progressive Subsets of Allowed Characters . . . . . . . . . . 5
4. Other corrections and updates . . . . . . . . . . . . . . . . 6 4. Considerations for For-Profit Domains . . . . . . . . . . . . 7
4.1. Updates to RFC 5890 . . . . . . . . . . . . . . . . . . . 7 5. Other corrections and updates . . . . . . . . . . . . . . . . 9
4.2. Updates to RFC 5891 . . . . . . . . . . . . . . . . . . . 8 5.1. Updates to RFC 5890 . . . . . . . . . . . . . . . . . . . 9
5. Related Discussions . . . . . . . . . . . . . . . . . . . . . 8 5.2. Updates to RFC 5891 . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Related Discussions . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . 12
A.1. Changes from version -00 (2017-03-11) to -01 . . . . . . 12 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 A.1. Changes from version -00 (2017-03-11) to -01 . . . . . . 14
A.2. Changes from version -01 (2017-09-12) to -02 . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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 29 skipping to change at page 3, line 30
The way in which the IDNA2008 specifications expressed these The way in which the IDNA2008 specifications expressed these
requirements may have obscured the intention that they actually are requirements may have obscured the intention that they actually are
requirements. Section 2.3.2.3 of the Definitions document [RFC5890] requirements. Section 2.3.2.3 of the Definitions document [RFC5890]
mentions the need for the restrictions, indicates that they are mentions the need for the restrictions, indicates that they are
mandatory, and points the reader to section 4.3 of the Protocol mandatory, and points the reader to section 4.3 of the Protocol
document [RFC5891], which in turn points to Section 3.2 of the document [RFC5891], which in turn points to Section 3.2 of the
Rationale document [RFC5894], with each document providing further Rationale document [RFC5894], with each document providing further
detail, discussion, and clarification. detail, discussion, and clarification.
At the same time, the Internet has evolved significantly since the
management assumptions for the DNS were established with RFC 1591 and
earlier. In particular, the management and use of domain names have
gone through several transformations. Recounting of those changes is
beyond the scope of this document but one of them has had significant
practical impact on the degree to which the requirement for registry
knowledge and responsibility is observed in practice. When RFC 1591
was written, the assumption was that domains at all levels of the DNS
would be operated in the best interest of the registrants in the
domain and of the Internet as a whole. There were no notions about
domains being operated for a profit and with a business model that
made them more profitable the more names that could be registered (or
even, under some circumstances, reserved and not registered) or that
domains would be considered more successful based on the number of
names registered and delegated from them. While rarely reflected in
the DNS protocols, the distinction between domains operated in those
ways and ones that are operated for, e.g., use within an enterprise
or otherwise as a service have become very important today. See
Section 4 for a discussion on how those issues affect this
specification.
This specification is intended to unify and clarify these This specification is intended to unify and clarify these
requirements for registry decisions and responsibility and to requirements for registry decisions and responsibility and to
emphasize the importance of registry restrictions at all levels of emphasize the importance of registry restrictions at all levels of
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",
skipping to change at page 5, line 5 skipping to change at page 5, line 28
contextual and whole label restrictions that provide further contextual and whole label restrictions that provide further
protection for registrants and users. For example, the widely-used protection for registrants and users. For example, the widely-used
principle that bars labels containing characters from more than one principle that bars labels containing characters from more than one
script is not an IDNA2008 requirement. It has been adopted by many script is not an IDNA2008 requirement. It has been adopted by many
registries but, as Section 4.4 of RFC 5890 indicates, there may be registries but, as Section 4.4 of RFC 5890 indicates, there may be
circumstances in 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 4 (MSR-4) for the Development of Label Generation Rules for the Root
Zone [ICANN-MSR2] (or its successor documents). Additional Zone [ICANN-MSR4] (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-3)
[ICANN-LGR1] (or its successor documents). [ICANN-LGR3] (or its successor documents). Many of these
recommendations also cover rules about relationships among code
points that may be particularly important for complex scripts and
recommendations on how to deal with alternate representations of the
same or apparently the same labels.
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; this restriction is not generally appropriate U+002D HYPHEN-MINUS; this restriction is not generally appropriate
for other zones. On the other hand, some zones may be designed to for other zones. On the other hand, some zones may be designed to
not cater for all users of a given script, but perhaps only for the not cater for all users of a given script, but perhaps only for the
needs of selected languages, in which case a more selective needs of selected languages, in which case a more selective
repertoire may be appropriate. repertoire may be appropriate.
skipping to change at page 6, line 47 skipping to change at page 7, line 26
recommendations such as the MSR do not allow should make such recommendations such as the MSR do not allow should make such
decisions only with great care and only if they have considerable decisions only with great care and only if they have considerable
understanding of, and great confidence in, their appropriateness. understanding of, and great confidence in, their appropriateness.
The obvious exception from the MSR would be to allow digits and the The obvious exception from the MSR would be to allow digits and the
hyphen. Neither were allowed by the MSR, but only because they are hyphen. Neither were allowed by the MSR, but only because they are
not allowed in the Root Zone. not allowed in the Root Zone.
Nothing in this document permits a registry to allow code points or Nothing in this document permits a registry to allow code points or
labels that are disallowed or otherwise prohibited by IDNA2008. labels that are disallowed or otherwise prohibited by IDNA2008.
4. Other corrections and updates 4. Considerations for For-Profit Domains
As discussed in the Introduction (Section 1), the distributed
administrative structure of the DNS today can be described by
dividing zones into two categories depending on how they are
administered and for whom. These categories are not precise -- some
zones may not fall neatly into one category or the other -- but are
useful in understanding the practical applicability of this
specification. They are:
Zones operating primarily or exclusively within an organization or
enterprise and responsible to that organization or enterprise.
DNS operations, including registrations and delegations, will
typically occur in support of the purpose of that organization or
enterprise rather than being its primary purpose.
Zones operating primarily on a for-profit basis in which most
delegations of subdomains are to entities with little or no no
affiliation with the registry operator other than contractual
agreements about operation of those subdomains. These zones are
often known as "public domains" or with similar terms, but those
terms often have other semantics and may not cover all cases.
Rules requiring strict registry responsibility, including either
thorough understanding of scripts and related issues in domain name
labels being considered for registration or local naming rules that
have the same effect, typically come naturally to registries for
zones of the first type. Registration of labels that would prove
problematic for any reason hurts the relevant organization or
enterprise or its customers. More generally, there are strong
incentives to be extremely conservative about labels that might be
registered and few, if any, incentives favoring adventures into
labels that might be considered clever, much less ones that are hard
to type, render, or, where it is relevant to users, remember
correctly.
By contrast, in a for-profit zone in which the profits are limited to
selling names, there may be perceived incentives to register whatever
names would-be registrants "want" or fears that any restrictions will
cut into the available namespace. In such situations, restrictions
are unlikely to be applied unless they meet at least one of two
criteria: (i) they are easy to apply and can be applied
algorithmically or otherwise automatically and/or (ii) there is clear
evidence that the particular label would cause harm.
As suggested above, the two categories above are not precise. In
particular, there may be domains that, despite being set up to
operate at a profit, are sufficiently conservative about their
operations to more closely resemble the first group in practice than
the second one.
The requirement of IDNA that is discussed at length elsewhere in this
specification stands: IDNA (and IDNs generally) would work better and
Internet users would be better protected and more secure if
registries and registrars (of any type) confined their registrations
to scripts and code point sequences that they understood thoroughly.
While the IETF rarely gives advice to those who choose to violate
IETF Standards, some advice to zones in the second category above may
be in order. That advice is that significant conservatism in what is
allowed to be registered, even for reservation purposes, and even
more conservatism about what labels are actually entered into zones
and delegated, is the best option for the Internet and its users. If
practical considerations do not allow that much conservatism, then it
is desirable to consult and utilize the many lists and tables that
have been, and continue to be, developed to advise on what might be
sensible for particular scripts (such as ICANN's efforts for script-
specific "generation rules" [[CREF1: Reference??? ]]) and lists of
code points or code point relationships that may be particularly
problematic and that should be treated with extra caution or
prohibited entirely such as the proposed "troublesome character" list
[Freytag-troublesome]. See also Section 6 below.
5. Other corrections and updates
After the initial IDNA2008 documents were published (and RFC 5892 was After the initial IDNA2008 documents were published (and RFC 5892 was
updated for Unicode 6.0 by RFC 6452 [RFC6452]) several errors or updated for Unicode 6.0 by RFC 6452 [RFC6452]) several errors or
instances of confusing text were noted. For the convenience of the instances of confusing text were noted. For the convenience of the
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 in this document.
4.1. Updates to RFC 5890 Readers should note that an update to RFC 5892 that is primarily
concerned with the review process for new versions of Unicode but
that makes some additional patches
[ID.draft-klensin-idna-unicode-review] is in progress. Its status
should be checked in conjunction with application of the present
specification.
5.1. Updates to RFC 5890
The outstanding errata against RFC 5890 (Errata ID 4695, 4696, 4823, The outstanding errata against RFC 5890 (Errata ID 4695, 4696, 4823,
and 4824 [RFC-Editor-5890Errata]) are all associated with the same and 4824 [RFC-Editor-5890Errata]) are all associated with the same
issue, the number of Unicode characters that can be associated with a issue, the number of Unicode characters that can be associated with a
maximum-length (63 octet) A-label. In retrospect and contrary to maximum-length (63 octet) A-label. In retrospect and contrary to
some of the suggestions in the errata, that value should not be some of the suggestions in the errata, that value should not be
expressed in octets because RFC 5890 and the other IDNA 2008 expressed in octets because RFC 5890 and the other IDNA 2008
documents are otherwise careful to not specify Unicode encoding forms documents are otherwise careful to not specify Unicode encoding forms
but, instead, work exclusively with Unicode code points. but, instead, work exclusively with Unicode code points.
Consequently the relevant material in RFC 5890 should be corrected as Consequently the relevant material in RFC 5890 should be corrected as
skipping to change at page 7, line 50 skipping to change at page 10, line 14
Old: Because A-labels (the form actually used in the DNS) are Old: Because A-labels (the form actually used in the DNS) are
potentially much more compressed than UTF-8 (and UTF-8 is, in potentially much more compressed than UTF-8 (and UTF-8 is, in
general, more compressed that UTF-16 or UTF-32), U-labels that general, more compressed that UTF-16 or UTF-32), U-labels that
obey all of the relevant symmetry (and other) constraints of obey all of the relevant symmetry (and other) constraints of
these documents may be quite a bit longer, potentially up to these documents may be quite a bit longer, potentially up to
252 characters (Unicode code points). 252 characters (Unicode code points).
New: A-labels (the form actually used in the DNS) and the New: A-labels (the form actually used in the DNS) and the
Punycode algorithm used as part of the process to produce them Punycode algorithm used as part of the process to produce them
[RFC3492] are strings that are potentially much more compressed [RFC3492] are strings that are potentially much more compressed
than any standard Unicode Encoding Form. [[CREF1: Do we need a than any standard Unicode Encoding Form. [[CREF2: Do we need a
reference for this here??]] A 63 octet A-label cannot reference for this here??]] A 63 octet A-label cannot represent
represent more than 58 Unicode code points (four octet overhead more than 58 Unicode code points (four octet overhead and the
and the requirement that at least one character lie outside the requirement that at least one character lie outside the ASCII
ASCII range) but implementations allocating buffer space for range) but implementations allocating buffer space for the
the conversion should allow significantly more space depending conversion should allow significantly more space depending on
on the encoding form they are using. the encoding form they are using.
4.2. Updates to RFC 5891 5.2. Updates to RFC 5891
Errata ID 3969: Improve reference for combining marks There is only Errata ID 3969: Improve reference for combining marks There is only
one erratum for RFC 5891, Errata ID 3969 [RFC5891Erratum]. one erratum for RFC 5891, Errata ID 3969 [RFC5891Erratum].
Combining marks are explained in the cited section, but not, as Combining marks are explained in the cited section, but not, as
the text indicates, exactly defined. the text indicates, exactly defined.
Old: The Unicode string MUST NOT begin with a combining mark or Old: The Unicode string MUST NOT begin with a combining mark or
combining character (see The Unicode Standard, Section 2.11 combining character (see The Unicode Standard, Section 2.11
[Unicode] for an exact definition). [Unicode] for an exact definition).
New: The Unicode string MUST NOT begin with a combining mark or New: The Unicode string MUST NOT begin with a combining mark or
combining character (see The Unicode Standard, Section 2.11 combining character (see The Unicode Standard, Section 2.11
[Unicode] for an explanation and Section 3.6, definition D52) [Unicode] for an explanation and Section 3.6, definition D52)
for an exact definition). for an exact definition).
Comment: When RFC 5891 is actually updated, the references in the Comment: When RFC 5891 is actually updated, the references in the
text should be updated to the current version of Unicode and text should be updated to the current version of Unicode and
the section numbers checked. the section numbers checked.
5. Related Discussions 6. Related Discussions
This document is one of a series of measures that have been suggested This document is one of a series of measures that have been suggested
to address IDNA issues raised in other documents, including to address IDNA issues raised in other documents, including
mechanisms for dealing with combining sequences and single-code point mechanisms for dealing with combining sequences and single-code point
characters with the same appearance that normalization neither characters with the same appearance that normalization neither
combines nor decomposes as IDNA2008 assumed [IDNA-Unicode], including combines nor decomposes as IDNA2008 assumed [IDNA-Unicode], including
the IAB response to that issue [IAB-2015], and to take a higher-level 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. view of issues, demands, and proposals for new uses of the DNS.
Those documents also include a discussion of issues with IDNA and Those documents also include a discussion of issues with IDNA and
character graphemes for which abstractions exist in Unicode in character graphemes for which abstractions exist in Unicode in
precomposed form but that can be generated from combining sequences precomposed form but that can be generated from combining sequences
and a suggested registry of code points known to be problematic and a suggested registry of code points known to be problematic
[Freytag-troublesome]. The discussion of combining sequences and [Freytag-troublesome]. The discussion of combining sequences and
non-decomposing characters is intended to lay the foundation for an non-decomposing characters is intended to lay the foundation for an
actual update to the IDNA code points document [RFC5892]. Such an actual update to the IDNA code points document [RFC5892]. Such an
update will presumably also address the existing errata against that update will presumably also address the existing errata against that
document. document.
6. Security Considerations 7. 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.
7. Acknowledgments 8. Acknowledgments
Many thanks to Patrik Faltstrom who provided an important review on Many thanks to Patrik Faltstrom who provided an important review on
the initial version. the initial version.
8. IANA Considerations 9. IANA Considerations
[[CREF2: RFC Editor: Please remove this section before publication.]] [[CREF3: 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.
9. References 10. References
9.1. Normative References 10.1. Normative References
[ICANN-LGR1] [ICANN-LGR3]
ICANN, "Root Zone Label Generation Rules (LGR-1)", June ICANN, "Root Zone Label Generation Rules (LGR-1)", July
2015, <https://www.icann.org/resources/pages/ 2019,
root-zone-lgr-2015-06-21-en>. <https://www.icann.org/news/announcement-2-2019-04-25-en>.
[ICANN-MSR2] [ICANN-MSR4]
ICANN, "Maximal Starting Repertoire Version 2 (MSR-2) for ICANN, "Maximal Starting Repertoire Version 4 (MSR-4) for
the Development of Label Generation Rules for the Root the Development of Label Generation Rules for the Root
Zone", April 2015, Zone", January 2019,
<https://www.icann.org/news/announcement-2-2015-04-27-en>. <https://www.icann.org/news/announcement-2019-02-07-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,
<https://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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 10, line 25 skipping to change at page 12, line 34
[RFC5891Erratum] [RFC5891Erratum]
"RFC 5891, "Internationalized Domain Names in Applications "RFC 5891, "Internationalized Domain Names in Applications
(IDNA): Protocol"", Errata ID 3969, April 2014, (IDNA): Protocol"", Errata ID 3969, April 2014,
<http://www.rfc-editor.org/errata_search.php?rfc=5891>. <http://www.rfc-editor.org/errata_search.php?rfc=5891>.
[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,
<https://www.rfc-editor.org/info/rfc5894>. <https://www.rfc-editor.org/info/rfc5894>.
9.2. Informative References 10.2. Informative References
[Freytag-troublesome] [Freytag-troublesome]
Freytag, A., Klensin, J., and A. Sullivan, "Those Freytag, A., Klensin, J., and A. Sullivan, "Those
Troublesome Characters: A Registry of Unicode Code Points Troublesome Characters: A Registry of Unicode Code Points
Needing Special Consideration When Used in Network Needing Special Consideration When Used in Network
Identifiers", June 2017, <draft-freytag-troublesome- Identifiers", June 2017, <draft-freytag-troublesome-
characters-01>. characters-01>.
[IAB-2015] [IAB-2015]
Internet Architecture Board (IAB), "IAB Statement on Internet Architecture Board (IAB), "IAB Statement on
Identifiers and Unicode 7.0.0", February 2015, Identifiers and Unicode 7.0.0", February 2015,
<https://www.iab.org/documents/ <https://www.iab.org/documents/
correspondence-reports-documents/2015-2/ correspondence-reports-documents/2015-2/
iab-statement-on-identifiers-and-unicode-7-0-0/>. iab-statement-on-identifiers-and-unicode-7-0-0/>.
[ID.draft-klensin-idna-unicode-review]
Klensin, J. and P. Faltstrom, "IDNA Review for New Unicode
Versions", June 2019, <https://datatracker.ietf.org/doc/
draft-klensin-idna-unicode-review/>.
[IDNA-Unicode] [IDNA-Unicode]
Klensin, J. and P. Falstrom, "IDNA Update for Unicode Klensin, J. and P. Falstrom, "IDNA Update for Unicode
7.0.0", September 2017, <draft-klensin-idna-5892upd- 7.0.0", September 2017, <draft-klensin-idna-5892upd-
unicode70-05>. 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,
skipping to change at page 12, line 18 skipping to change at page 14, line 39
<https://www.rfc-editor.org/info/rfc6912>. <https://www.rfc-editor.org/info/rfc6912>.
Appendix A. Change Log Appendix A. Change Log
RFC Editor: Please remove this appendix before publication. RFC Editor: Please remove this appendix before publication.
A.1. Changes from version -00 (2017-03-11) to -01 A.1. Changes from version -00 (2017-03-11) to -01
o Added Acknowledgments and adjusted references. o Added Acknowledgments and adjusted references.
o Filled in Section 4 with updates to respond to errata. o Filled in Section 5 with updates to respond to errata.
o Added Section 5 to discuss relationships to other documents. o Added Section 6 to discuss relationships to other documents.
o Modified the Abstract to note specifically updated documents. o Modified the Abstract to note specifically updated documents.
o Several small editorial changes and corrections. o Several small editorial changes and corrections.
A.2. Changes from version -01 (2017-09-12) to -02
After pause of nearly 34 months due to inability to get this draft
processed, including nearly a year waiting for a new directorate to
actually do anything of substance about fundamental IDNA issues, the
-02 version is being posted in the hope of getting a new start.
Specific changes include:
o Added a new section, Section 4, and some introductory material to
address the very practical issue that domains run on a for-profit
basis are unlikely to follow the very strict "understand what you
are registering" requirement if they support IDNs at all and
expect to profit from them.
o Added a pointer to draft-klensin-idna-unicode-review to the
discussion of other work.
o Editorial corrections and changes.
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. 29 change blocks. 
57 lines changed or deleted 187 lines changed or added

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