< draft-ietf-idnabis-rationale-14.txt   draft-ietf-idnabis-rationale-15.txt >
Network Working Group J. Klensin Network Working Group J. Klensin
Internet-Draft October 25, 2009 Internet-Draft December 15, 2009
Intended status: Informational Intended status: Informational
Expires: April 28, 2010 Expires: June 18, 2010
Internationalized Domain Names for Applications (IDNA): Background, Internationalized Domain Names for Applications (IDNA): Background,
Explanation, and Rationale Explanation, and Rationale
draft-ietf-idnabis-rationale-14.txt draft-ietf-idnabis-rationale-15.txt
Abstract
Several years have passed since the original protocol for
Internationalized Domain Names (IDNs) was completed and deployed.
During that time, a number of issues have arisen, including the need
to update the system to deal with newer versions of Unicode. Some of
these issues require tuning of the existing protocols and the tables
on which they depend. This document provides an overview of a
revised system and provides explanatory material for its components.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 28, 2010. This Internet-Draft will expire on June 18, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Several years have passed since the original protocol for This document may contain material from IETF Documents or IETF
Internationalized Domain Names (IDNs) was completed and deployed. Contributions published or made publicly available before November
During that time, a number of issues have arisen, including the need 10, 2008. The person(s) controlling the copyright in some of this
to update the system to deal with newer versions of Unicode. Some of material may not have granted the IETF Trust the right to allow
these issues require tuning of the existing protocols and the tables modifications of such material outside the IETF Standards Process.
on which they depend. This document provides an overview of a Without obtaining an adequate license from the person(s) controlling
revised system and provides explanatory material for its components. the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Context and Overview . . . . . . . . . . . . . . . . . . . 5 1.1. Context and Overview . . . . . . . . . . . . . . . . . . . 4
1.2. Discussion Forum . . . . . . . . . . . . . . . . . . . . . 6 1.2. Discussion Forum . . . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1. DNS "Name" Terminology . . . . . . . . . . . . . . . . 6 1.3.1. DNS "Name" Terminology . . . . . . . . . . . . . . . . 5
1.3.2. New Terminology and Restrictions . . . . . . . . . . . 7 1.3.2. New Terminology and Restrictions . . . . . . . . . . . 6
1.4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5. Applicability and Function of IDNA . . . . . . . . . . . . 8 1.5. Applicability and Function of IDNA . . . . . . . . . . . . 7
1.6. Comprehensibility of IDNA Mechanisms and Processing . . . 9 1.6. Comprehensibility of IDNA Mechanisms and Processing . . . 8
2. Processing in IDNA2008 . . . . . . . . . . . . . . . . . . . . 10 2. Processing in IDNA2008 . . . . . . . . . . . . . . . . . . . . 9
3. Permitted Characters: An Inclusion List . . . . . . . . . . . 10 3. Permitted Characters: An Inclusion List . . . . . . . . . . . 9
3.1. A Tiered Model of Permitted Characters and Labels . . . . 11 3.1. A Tiered Model of Permitted Characters and Labels . . . . 10
3.1.1. PROTOCOL-VALID . . . . . . . . . . . . . . . . . . . . 11 3.1.1. PROTOCOL-VALID . . . . . . . . . . . . . . . . . . . . 10
3.1.2. CONTEXTUAL RULE REQUIRED . . . . . . . . . . . . . . . 12 3.1.2. CONTEXTUAL RULE REQUIRED . . . . . . . . . . . . . . . 11
3.1.2.1. Contextual Restrictions . . . . . . . . . . . . . 12 3.1.2.1. Contextual Restrictions . . . . . . . . . . . . . 11
3.1.2.2. Rules and Their Application . . . . . . . . . . . 13 3.1.2.2. Rules and Their Application . . . . . . . . . . . 12
3.1.3. DISALLOWED . . . . . . . . . . . . . . . . . . . . . . 13 3.1.3. DISALLOWED . . . . . . . . . . . . . . . . . . . . . . 12
3.1.4. UNASSIGNED . . . . . . . . . . . . . . . . . . . . . . 14 3.1.4. UNASSIGNED . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Registration Policy . . . . . . . . . . . . . . . . . . . 14 3.2. Registration Policy . . . . . . . . . . . . . . . . . . . 13
3.3. Layered Restrictions: Tables, Context, Registration, 3.3. Layered Restrictions: Tables, Context, Registration,
Applications . . . . . . . . . . . . . . . . . . . . . . . 15 Applications . . . . . . . . . . . . . . . . . . . . . . . 14
4. Issues that Constrain Possible Solutions . . . . . . . . . . . 16 4. Issues that Constrain Possible Solutions . . . . . . . . . . . 15
4.1. Display and Network Order . . . . . . . . . . . . . . . . 16 4.1. Display and Network Order . . . . . . . . . . . . . . . . 15
4.2. Entry and Display in Applications . . . . . . . . . . . . 17 4.2. Entry and Display in Applications . . . . . . . . . . . . 16
4.3. Linguistic Expectations: Ligatures, Digraphs, and 4.3. Linguistic Expectations: Ligatures, Digraphs, and
Alternate Character Forms . . . . . . . . . . . . . . . . 19 Alternate Character Forms . . . . . . . . . . . . . . . . 18
4.4. Case Mapping and Related Issues . . . . . . . . . . . . . 21 4.4. Case Mapping and Related Issues . . . . . . . . . . . . . 20
4.5. Right to Left Text . . . . . . . . . . . . . . . . . . . . 22 4.5. Right to Left Text . . . . . . . . . . . . . . . . . . . . 21
5. IDNs and the Robustness Principle . . . . . . . . . . . . . . 22 5. IDNs and the Robustness Principle . . . . . . . . . . . . . . 21
6. Front-end and User Interface Processing for Lookup . . . . . . 23 6. Front-end and User Interface Processing for Lookup . . . . . . 22
7. Migration from IDNA2003 and Unicode Version Synchronization . 25 7. Migration from IDNA2003 and Unicode Version Synchronization . 24
7.1. Design Criteria . . . . . . . . . . . . . . . . . . . . . 25 7.1. Design Criteria . . . . . . . . . . . . . . . . . . . . . 24
7.1.1. Summary and Discussion of IDNA Validity Criteria . . . 25 7.1.1. Summary and Discussion of IDNA Validity Criteria . . . 24
7.1.2. Labels in Registration . . . . . . . . . . . . . . . . 26 7.1.2. Labels in Registration . . . . . . . . . . . . . . . . 25
7.1.3. Labels in Lookup . . . . . . . . . . . . . . . . . . . 27 7.1.3. Labels in Lookup . . . . . . . . . . . . . . . . . . . 26
7.2. Changes in Character Interpretations . . . . . . . . . . . 29 7.2. Changes in Character Interpretations . . . . . . . . . . . 28
7.3. Character Mapping . . . . . . . . . . . . . . . . . . . . 30 7.2.1. Character Changes: Eszett and Final Sigma . . . . . . 28
7.2.2. Character Changes: Zero-Width Joiner and Non-Joiner . 28
7.2.3. Character Changes and the Need for Transition . . . . 28
7.2.4. Transition Strategies . . . . . . . . . . . . . . . . 29
7.3. Elimination of Character Mapping . . . . . . . . . . . . . 30
7.4. The Question of Prefix Changes . . . . . . . . . . . . . . 30 7.4. The Question of Prefix Changes . . . . . . . . . . . . . . 30
7.4.1. Conditions Requiring a Prefix Change . . . . . . . . . 30 7.4.1. Conditions Requiring a Prefix Change . . . . . . . . . 31
7.4.2. Conditions Not Requiring a Prefix Change . . . . . . . 31 7.4.2. Conditions Not Requiring a Prefix Change . . . . . . . 31
7.4.3. Implications of Prefix Changes . . . . . . . . . . . . 31 7.4.3. Implications of Prefix Changes . . . . . . . . . . . . 32
7.5. Stringprep Changes and Compatibility . . . . . . . . . . . 32 7.5. Stringprep Changes and Compatibility . . . . . . . . . . . 32
7.6. The Symbol Question . . . . . . . . . . . . . . . . . . . 32 7.6. The Symbol Question . . . . . . . . . . . . . . . . . . . 33
7.7. Migration Between Unicode Versions: Unassigned Code 7.7. Migration Between Unicode Versions: Unassigned Code
Points . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Points . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.8. Other Compatibility Issues . . . . . . . . . . . . . . . . 36 7.8. Other Compatibility Issues . . . . . . . . . . . . . . . . 36
8. Name Server Considerations . . . . . . . . . . . . . . . . . . 36 8. Name Server Considerations . . . . . . . . . . . . . . . . . . 36
8.1. Processing Non-ASCII Strings . . . . . . . . . . . . . . . 36 8.1. Processing Non-ASCII Strings . . . . . . . . . . . . . . . 36
8.2. Root and other DNS Server Considerations . . . . . . . . . 37 8.2. Root and other DNS Server Considerations . . . . . . . . . 37
9. Internationalization Considerations . . . . . . . . . . . . . 37 9. Internationalization Considerations . . . . . . . . . . . . . 37
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
10.1. IDNA Character Registry . . . . . . . . . . . . . . . . . 37 10.1. IDNA Character Registry . . . . . . . . . . . . . . . . . 38
10.2. IDNA Context Registry . . . . . . . . . . . . . . . . . . 38 10.2. IDNA Context Registry . . . . . . . . . . . . . . . . . . 38
10.3. IANA Repository of IDN Practices of TLDs . . . . . . . . . 38 10.3. IANA Repository of IDN Practices of TLDs . . . . . . . . . 38
11. Security Considerations . . . . . . . . . . . . . . . . . . . 38 11. Security Considerations . . . . . . . . . . . . . . . . . . . 38
11.1. General Security Issues with IDNA . . . . . . . . . . . . 38 11.1. General Security Issues with IDNA . . . . . . . . . . . . 38
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 39 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 39
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
14.1. Normative References . . . . . . . . . . . . . . . . . . . 40 14.1. Normative References . . . . . . . . . . . . . . . . . . . 40
14.2. Informative References . . . . . . . . . . . . . . . . . . 41 14.2. Informative References . . . . . . . . . . . . . . . . . . 41
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 43 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 43
A.1. Changes between Version -00 and Version -01 of A.1. Changes between Version -00 and Version -01 of
draft-ietf-idnabis-rationale . . . . . . . . . . . . . . . 43 draft-ietf-idnabis-rationale . . . . . . . . . . . . . . . 43
A.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 44 A.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 44
A.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 44 A.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 44
A.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 44 A.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 45
A.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 45 A.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 45
A.6. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 45 A.6. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 45
A.7. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 46 A.7. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 46
A.8. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 46 A.8. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 46
A.9. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 46 A.9. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 46
A.10. Version -10 . . . . . . . . . . . . . . . . . . . . . . . 47 A.10. Version -10 . . . . . . . . . . . . . . . . . . . . . . . 47
A.11. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 47 A.11. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 47
A.12. Version -12 . . . . . . . . . . . . . . . . . . . . . . . 47 A.12. Version -12 . . . . . . . . . . . . . . . . . . . . . . . 48
A.13. Version -13 . . . . . . . . . . . . . . . . . . . . . . . 48 A.13. Version -13 . . . . . . . . . . . . . . . . . . . . . . . 48
A.14. Version -14 . . . . . . . . . . . . . . . . . . . . . . . 48 A.14. Version -14 . . . . . . . . . . . . . . . . . . . . . . . 48
A.15. Version -14 . . . . . . . . . . . . . . . . . . . . . . . 48 A.15. Version -15 . . . . . . . . . . . . . . . . . . . . . . . 49
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 48 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
1.1. Context and Overview 1.1. Context and Overview
Internationalized Domain Names in Applications (IDNA) is a collection Internationalized Domain Names in Applications (IDNA) is a collection
of standards that allow client applications to convert some Unicode of standards that allow client applications to convert some Unicode
mnemonics to an ASCII-compatible encoding form ("ACE") which is a mnemonics to an ASCII-compatible encoding form ("ACE") which is a
valid DNS label containing only letters, digits, and hyphens. The valid DNS label containing only letters, digits, and hyphens. The
specific form of ACE label used by IDNA is called an "A-label". A specific form of ACE label used by IDNA is called an "A-label". A
skipping to change at page 29, line 7 skipping to change at page 29, line 7
date to interpret all of the characters in the label. Messages to date to interpret all of the characters in the label. Messages to
users should distinguish between "label contains an unallocated code users should distinguish between "label contains an unallocated code
point" and other types of lookup failures. A failure on the basis of point" and other types of lookup failures. A failure on the basis of
an old version of Unicode may lead the user to a desire to upgrade to an old version of Unicode may lead the user to a desire to upgrade to
a newer version, but will have no other ill effects (this is a newer version, but will have no other ill effects (this is
consistent with behavior in the transition to the DNS when some hosts consistent with behavior in the transition to the DNS when some hosts
could not yet handle some forms of names or record types). could not yet handle some forms of names or record types).
7.2. Changes in Character Interpretations 7.2. Changes in Character Interpretations
As a consequence of the elimination of mapping, the current version
of IDNA changes the interpretation of a few characters relative to
its predecessors. This subsection outlines the issues and discusses
possible transition strategies.
7.2.1. Character Changes: Eszett and Final Sigma
In those scripts that make case distinctions, there are a few In those scripts that make case distinctions, there are a few
characters for which an obvious and unique upper case character has characters for which an obvious and unique upper case character has
not historically been available to match a lower case one or vice not historically been available to match a lower case one or vice
versa. For those characters, the mappings used in constructing the versa. For those characters, the mappings used in constructing the
Stringprep tables for IDNA2003, performed using the Unicode CaseFold Stringprep tables for IDNA2003, performed using the Unicode CaseFold
operation (See Section 5.8 of the Unicode Standard [Unicode51]), operation (See Section 5.8 of the Unicode Standard [Unicode51]),
generate different characters or sets of characters. Those generate different characters or sets of characters. Those
operations are not reversible and lose even more information than operations are not reversible and lose even more information than
traditional upper case or lower case transformations, but are more traditional upper case or lower case transformations, but are more
useful than those transformations for comparison purposes. Two useful than those transformations for comparison purposes. Two
notable characters of this type are the German character Eszett notable characters of this type are the German character Eszett
(Sharp S, U+00DF) and the Greek Final Form Sigma (U+03C2). The (Sharp S, U+00DF) and the Greek Final Form Sigma (U+03C2). The
former is case-folded to the ASCII string "ss", the latter to a former is case-folded to the ASCII string "ss", the latter to a
medial (Lower Case) Sigma (U+03C3). medial (Lower Case) Sigma (U+03C3).
7.2.2. Character Changes: Zero-Width Joiner and Non-Joiner
IDNA2003 mapped both Zero-Width Joiner (ZWJ, U+200D) and Zero-Width
Non-Joiner (ZWNJ, U+200C) to nothing, effectively dropping these
characters from any label in which they appeared and treating strings
containing them as identical to strings that did not. As discussed
in Section 3.1.2 above, those characters are essential for writing
many reasonable mnemonics for certain scripts. However, treating
them as valid in the current version of IDNA, even with contextual
restrictions, raises approximately the same problem as exists with
Eszett and Final Sigma: strings that were valid under IDNA2003 have
different interpretations as labels, and different A-labels, than the
same strings under this newer version.
7.2.3. Character Changes and the Need for Transition
The decision to eliminate mandatory and standardized mappings, The decision to eliminate mandatory and standardized mappings,
including case folding, from the IDNA2008 protocol in order to make including case folding, from the IDNA2008 protocol in order to make
A-labels and U-labels idempotent made these characters problematic. A-labels and U-labels idempotent made these characters problematic.
If they were to be disallowed, important words and mnemonics could If they were to be disallowed, important words and mnemonics could
not be written in orthographically reasonable ways. If they were to not be written in orthographically reasonable ways. If they were to
be permitted as distinct characters, there would be no information be permitted as distinct characters, there would be no information
loss and registries would have more flexibility, but IDNA2003 and loss and registries would have more flexibility, but IDNA2003 and
IDNA2008 lookups might result in different A-labels. IDNA2008 lookups might result in different A-labels.
With the understanding that there would be incompatibility either way With the understanding that there would be incompatibility either way
but a judgment that the incompatibility was not significant enough to but a judgment that the incompatibility was not significant enough to
justify a prefix change, the WG concluded that Eszett and Final Form justify a prefix change, the WG concluded that Eszett and Final Form
Sigma should be treated as distinct and Protocol-Valid characters. Sigma should be treated as distinct and Protocol-Valid characters.
Since these characters are interpreted in different ways under the
older and newer versions of IDNA, transition strategies and policies
will be necessary. Some actions can reasonably be taken by
applications client programs (those that perform lookup operations or
cause them to be performed) but, because of the diversity of
situations and uses of the DNS, much of the responsibility will need
to fall on registries.
Registries, especially those maintaining zones for third parties, Registries, especially those maintaining zones for third parties,
must decide how to introduce a new service in a way that does not must decide how to introduce a new service in a way that does not
create confusion or significantly weaken or invalidate existing create confusion or significantly weaken or invalidate existing
identifiers. This is not a new problem; registries were faced with identifiers. This is not a new problem; registries were faced with
similar issues when IDNs were introduced and when other new forms of similar issues when IDNs were introduced (potentially, and especially
strings have been permitted as labels. for Latin-based scripts, in conflict with existing labels that had
been rendered in ASCII character by applying more or less
standardized conventions) and when other new forms of strings have
been permitted as labels.
There are several approaches to problems of this type. Without any 7.2.4. Transition Strategies
preference or claim to completeness, some of these, all of which have
been used by registries in the past for similar transitions, are:
o Do not permit use of the newly-available character at the registry There are several approaches to the introduction of new characters or
level. This might cause lookup failures if a domain name were to changes in interpretation of existing characters from their mapped
be written with the expectation of the IDNA2003 mapping behavior, forms in the earlier version of IDNA. The transition issue is
but would eliminate any possibility of false matches. complicated because the forms of these labels after
ToUnicode(ToASCII()) translation in IDNA2003 not only remain valid
but do not provide strong indications of what the registrant
intended: a string containing "ss" could have simply been intended to
be that string or could have been intended to contain an Eszett, a
string containing lower-case Sigma could have been intended to
contain Final Sigma (one might make heuristic guesses based on
position in a string, but the long tradition of forming labels by
concatenating words makes such heuristics unreliable), and strings
that do not contain ZWJ or ZWNJ might have been intended to contain
them. Without any preference or claim to completeness, some of
these, all of which have been used by registries in the past for
similar transitions, are:
o Hold a "sunrise"-like arrangement in which holders of labels 1. Do not permit use of the newly-available character at the
containing "ss" in the Eszett case or Lower Case Sigma are given registry level. This might cause lookup failures if a domain
priority (and perhaps other benefits) for registering the name were to be written with the expectation of the IDNA2003
corresponding string containing Eszett or Final Sigma mapping behavior, but would eliminate any possibility of false
respectively. matches.
o Adopt some sort of "variant" approach in which registrants obtain 2. Hold a "sunrise"-like arrangement in which holders of labels
labels with both character forms. containing "ss" in the Eszett case, Lower Case Sigma in that
case, or that might have contained ZWJ or ZWNJ in context, are
given priority (and perhaps other benefits) for registering the
corresponding string containing Eszett, Final Sigma, or the
appropriate Zero-width character respectively.
o Adopt a different form of "variant" approach in which registration 3. Adopt some sort of "variant" approach in which registrants obtain
of additional names is either not permitted at all or permitted labels with both character forms.
only by the registrant who already has one of the names.
7.3. Character Mapping 4. Adopt a different form of "variant" approach in which
registration of additional strings that would produce the same
A-label if interpreted according to IDNA2003 is either not
permitted at all or permitted only by the registrant who already
has one of the names.
5. Ignore the issue and assume that the marketplace or other
mechanisms will sort things out.
In any event, a registry (at any level of the DNS tree) that chooses
to permit labels to be registered that contains these characters, or
considers doing so, will have to address the relationship with
existing, possibly-conflicting, labels in some way, just as
registries that already had a considerable number of labels did when
IDNs were first introduced.
7.3. Elimination of Character Mapping
As discussed at length in Section 6, IDNA2003, via Nameprep (see As discussed at length in Section 6, IDNA2003, via Nameprep (see
Section 7.5), mapped many characters into related ones. Those Section 7.5), mapped many characters into related ones. Those
mappings no longer exist as requirements in IDNA2008. These mappings no longer exist as requirements in IDNA2008. These
specifications strongly prefer that only A-labels or U-labels be used specifications strongly prefer that only A-labels or U-labels be used
in protocol contexts and as much as practical more generally. in protocol contexts and as much as practical more generally.
IDNA2008 does anticipate situations in which some mapping at the time IDNA2008 does anticipate situations in which some mapping at the time
of user input into lookup applications is appropriate and desirable. of user input into lookup applications is appropriate and desirable.
The issues are discussed in Section 6 and specific recommendations The issues are discussed in Section 6 and specific recommendations
are made in [IDNA2008-Mapping]. are made in [IDNA2008-Mapping].
skipping to change at page 48, line 19 skipping to change at page 49, line 26
o Small typographical and editorial corrections. o Small typographical and editorial corrections.
A.13. Version -13 A.13. Version -13
o Substituted in Section numbers to references to other IDNA2008 o Substituted in Section numbers to references to other IDNA2008
documents. documents.
A.14. Version -14 A.14. Version -14
A.15. Version -14
This is the version of the document produced to reflect comments on This is the version of the document produced to reflect comments on
IETF Last Call. For the convenience of those who made comments and IETF Last Call. For the convenience of those who made comments and
of the IESG in evaluating them, this section therefore identifies of the IESG in evaluating them, this section therefore identifies
non-editorial changes made in response to Last Call comments in non-editorial changes made in response to Last Call comments in
somewhat more detail than may be usual. somewhat more detail than may be usual.
o Removed the discussion of DNSSEC after extensive discussion on the o Removed the discussion of DNSSEC after extensive discussion on the
IETF and IDNABIS lists. IETF and IDNABIS lists.
o Modified the discussion of prefix changes to make it clear that o Modified the discussion of prefix changes to make it clear that
skipping to change at page 49, line 5 skipping to change at page 50, line 5
protocols that use IDNA. Peter Saint-Andre, 20091019. protocols that use IDNA. Peter Saint-Andre, 20091019.
o Several other clarifications as suggested by Peter Saint-Andre, o Several other clarifications as suggested by Peter Saint-Andre,
20091019. 20091019.
o Several minor editorial corrections per suggestions in Ben o Several minor editorial corrections per suggestions in Ben
Campbell's Gen-ART review 20091013. Campbell's Gen-ART review 20091013.
o Typo corrections. o Typo corrections.
A.15. Version -15
o Rewrote and expanded the "transition" material of Section 7.2.
Author's Address Author's Address
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. 30 change blocks. 
95 lines changed or deleted 170 lines changed or added

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