< draft-ietf-idnabis-rationale-08.txt   draft-ietf-idnabis-rationale-09.txt >
Network Working Group J. Klensin Network Working Group J. Klensin
Internet-Draft March 6, 2009 Internet-Draft March 9, 2009
Intended status: Informational Intended status: Informational
Expires: September 7, 2009 Expires: September 10, 2009
Internationalized Domain Names for Applications (IDNA): Background, Internationalized Domain Names for Applications (IDNA): Background,
Explanation, and Rationale Explanation, and Rationale
draft-ietf-idnabis-rationale-08.txt draft-ietf-idnabis-rationale-09.txt
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. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 September 7, 2009. This Internet-Draft will expire on September 10, 2009.
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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 21 skipping to change at page 3, line 21
7.3. More Flexibility in User Agents . . . . . . . . . . . . . 30 7.3. More Flexibility in User Agents . . . . . . . . . . . . . 30
7.4. The Question of Prefix Changes . . . . . . . . . . . . . . 31 7.4. The Question of Prefix Changes . . . . . . . . . . . . . . 31
7.4.1. Conditions Requiring a Prefix Change . . . . . . . . . 32 7.4.1. Conditions Requiring a Prefix Change . . . . . . . . . 32
7.4.2. Conditions Not Requiring a Prefix Change . . . . . . . 32 7.4.2. Conditions Not Requiring a Prefix Change . . . . . . . 32
7.4.3. Implications of Prefix Changes . . . . . . . . . . . . 33 7.4.3. Implications of Prefix Changes . . . . . . . . . . . . 33
7.5. Stringprep Changes and Compatibility . . . . . . . . . . . 33 7.5. Stringprep Changes and Compatibility . . . . . . . . . . . 33
7.6. The Symbol Question . . . . . . . . . . . . . . . . . . . 34 7.6. The Symbol Question . . . . . . . . . . . . . . . . . . . 34
7.7. Migration Between Unicode Versions: Unassigned Code 7.7. Migration Between Unicode Versions: Unassigned Code
Points . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Points . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.8. Other Compatibility Issues . . . . . . . . . . . . . . . . 37 7.8. Other Compatibility Issues . . . . . . . . . . . . . . . . 37
8. Name Server Considerations . . . . . . . . . . . . . . . . . . 37 8. Name Server Considerations . . . . . . . . . . . . . . . . . . 38
8.1. Processing Non-ASCII Strings . . . . . . . . . . . . . . . 37 8.1. Processing Non-ASCII Strings . . . . . . . . . . . . . . . 38
8.2. DNSSEC Authentication of IDN Domain Names . . . . . . . . 38 8.2. DNSSEC Authentication of IDN Domain Names . . . . . . . . 38
8.3. Root and other DNS Server Considerations . . . . . . . . . 38 8.3. Root and other DNS Server Considerations . . . . . . . . . 39
9. Internationalization Considerations . . . . . . . . . . . . . 39 9. Internationalization Considerations . . . . . . . . . . . . . 39
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
10.1. IDNA Character Registry . . . . . . . . . . . . . . . . . 39 10.1. IDNA Character Registry . . . . . . . . . . . . . . . . . 40
10.2. IDNA Context Registry . . . . . . . . . . . . . . . . . . 39 10.2. IDNA Context Registry . . . . . . . . . . . . . . . . . . 40
10.3. IANA Repository of IDN Practices of TLDs . . . . . . . . . 39 10.3. IANA Repository of IDN Practices of TLDs . . . . . . . . . 40
11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40
11.1. General Security Issues with IDNA . . . . . . . . . . . . 40 11.1. General Security Issues with IDNA . . . . . . . . . . . . 40
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 41 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 41
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
14.1. Normative References . . . . . . . . . . . . . . . . . . . 41 14.1. Normative References . . . . . . . . . . . . . . . . . . . 42
14.2. Informative References . . . . . . . . . . . . . . . . . . 42 14.2. Informative References . . . . . . . . . . . . . . . . . . 43
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 44 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 45
A.1. Changes between Version -00 and Version -01 of A.1. Changes between Version -00 and Version -01 of
draft-ietf-idnabis-rationale . . . . . . . . . . . . . . . 44 draft-ietf-idnabis-rationale . . . . . . . . . . . . . . . 45
A.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 45 A.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 46
A.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 45 A.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 46
A.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 46 A.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 46
A.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 46 A.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 47
A.6. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 46 A.6. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 47
A.7. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 47 A.7. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 48
A.8. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 47 A.8. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 48
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47 A.9. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 48
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
1.1. Context and Overview 1.1. Context and Overview
The original standards for Internationalized Domain Names (IDNs) were The original standards for Internationalized Domain Names (IDNs) were
completed and deployed starting in 2003. Those standards are known completed and deployed starting in 2003. Those standards are known
as Internationalized Domain Names in Applications (IDNA), taken from as Internationalized Domain Names in Applications (IDNA), taken from
the name of the highest level standard within the group, RFC 3490 the name of the highest level standard within the group, RFC 3490
[RFC3490]. After those standards were deployed, a number of issues [RFC3490]. After those standards were deployed, a number of issues
skipping to change at page 6, line 23 skipping to change at page 6, line 23
In addition, the term "putative label" has been adopted to refer to a In addition, the term "putative label" has been adopted to refer to a
label that may appear to meet certain definitional constraints but label that may appear to meet certain definitional constraints but
has not yet been sufficiently tested for validity. has not yet been sufficiently tested for validity.
These definitions are illustrated in Figure 1 of the Definitions These definitions are illustrated in Figure 1 of the Definitions
Document [IDNA2008-Defs]. R-LDH-labels contain "--" in the third and Document [IDNA2008-Defs]. R-LDH-labels contain "--" in the third and
fourth character from the beginning of the label. In IDNA-aware fourth character from the beginning of the label. In IDNA-aware
applications, only a subset of these reserved labels is permitted to applications, only a subset of these reserved labels is permitted to
be used, namely the A-label subset. A-labels are a subset of the be used, namely the A-label subset. A-labels are a subset of the
R-LDH-labels that begin with the case-insensitive (?) string "xn--". R-LDH-labels that begin with the case-insensitive string "xn--".
Labels that bear this prefix but which are not otherwise valid fall Labels that bear this prefix but which are not otherwise valid fall
into the "Fake-A-label" category. The non-reserved labels (NR-LDH- into the "Fake-A-label" category. The non-reserved labels (NR-LDH-
labels) are implicitly valid since they do not trigger any labels) are implicitly valid since they do not trigger any
resemblance to IDNA-landr NR-LDH-labels. resemblance to IDNA-landr NR-LDH-labels.
The creation of the Reserved-LDH category is required for three The creation of the Reserved-LDH category is required for three
reasons: reasons:
o to prevent confusion with pre-IDNA coding forms; o to prevent confusion with pre-IDNA coding forms;
skipping to change at page 7, line 27 skipping to change at page 7, line 27
1.5. Applicability and Function of IDNA 1.5. Applicability and Function of IDNA
The IDNA specification solves the problem of extending the repertoire The IDNA specification solves the problem of extending the repertoire
of characters that can be used in domain names to include a large of characters that can be used in domain names to include a large
subset of the Unicode repertoire. subset of the Unicode repertoire.
IDNA does not extend the service offered by DNS to the applications. IDNA does not extend the service offered by DNS to the applications.
Instead, the applications (and, by implication, the users) continue Instead, the applications (and, by implication, the users) continue
to see an exact-match lookup service. Either there is a single to see an exact-match lookup service. Either there is a single
exactly-matching name or there is no match. This model has served exactly-matching (subject to the base DNS requirement of case-
the existing applications well, but it requires, with or without insensitive ASCII matching) name or there is no match. This model
internationalized domain names, that users know the exact spelling of has served the existing applications well, but it requires, with or
the domain names that are to be typed into applications such as web without internationalized domain names, that users know the exact
browsers and mail user agents. The introduction of the larger spelling of the domain names that are to be typed into applications
repertoire of characters potentially makes the set of misspellings such as web browsers and mail user agents. The introduction of the
larger, especially given that in some cases the same appearance, for larger repertoire of characters potentially makes the set of
example on a business card, might visually match several Unicode code misspellings larger, especially given that in some cases the same
points or several sequences of code points. appearance, for example on a business card, might visually match
several Unicode code points or several sequences of code points.
The IDNA standard does not require any applications to conform to it, The IDNA standard does not require any applications to conform to it,
nor does it retroactively change those applications. An application nor does it retroactively change those applications. An application
can elect to use IDNA in order to support IDN while maintaining can elect to use IDNA in order to support IDN while maintaining
interoperability with existing infrastructure. If an application interoperability with existing infrastructure. If an application
wants to use non-ASCII characters in domain names, IDNA is the only wants to use non-ASCII characters in domain names, IDNA is the only
currently-defined option. Adding IDNA support to an existing currently-defined option. Adding IDNA support to an existing
application entails changes to the application only, and leaves room application entails changes to the application only, and leaves room
for flexibility in front-end processing and more specifically in the for flexibility in front-end processing and more specifically in the
user interface (see Section 6). user interface (see Section 6).
skipping to change at page 29, line 32 skipping to change at page 29, line 32
characters distinct from the forms produced by case folding, there characters distinct from the forms produced by case folding, there
would be no information loss and registries would have maximum would be no information loss and registries would have maximum
flexibility, but labels using those characters that were looked up flexibility, but labels using those characters that were looked up
according to IDNA2003 rules would be transformed into A-labels using according to IDNA2003 rules would be transformed into A-labels using
their case-mapped variations while lookup according to IDNA2008 rules their case-mapped variations while lookup according to IDNA2008 rules
would be based on different A-labels that represented the actual would be based on different A-labels that represented the actual
characters. characters.
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
just 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.
The decision faces registries, especially registries maintaining The decision faces registries, especially registries maintaining
zones for third parties, with a variation on what has become a zones for third parties, with a variation on what has become a
familiar problem: how to introduce a new service in a way that does familiar problem: how to introduce a new service in a way that does
not create confusion or significantly weaken or invalidate existing not create confusion or significantly weaken or invalidate existing
identifiers. identifiers.
There have traditionally been several approaches to problems of this There have traditionally been several approaches to problems of this
type. Without any preference or claim to completeness, these are: type. Without any preference or claim to completeness, these are:
o Do not permit use of the newly-available character at the registry o Do not permit use of the newly-available character at the registry
level. This might cause lookup failures if a domain name were to level. This might cause lookup failures if a domain name were to
be written with the expectation of the IDNA2003 mapping behavior, be written with the expectation of the IDNA2003 mapping behavior,
but would eliminate any possibility of false matches. but would eliminate any possibility of false matches.
o Hold a "sunrise"-like arrangement in which holders of the o Hold a "sunrise"-like arrangement in which holders of labels that
previously-mapped labels (labels containing "ss" in the Eszett might have resulted from previous mapping (labels containing "ss"
case or ones containing Lower Case Sigma in the Final Sigma case) in the Eszett case or ones containing Lower Case Sigma in the
are given priority (and perhaps other benefits) for registering Final Sigma case) are given priority (and perhaps other benefits)
the corresponding string containing the newly-available for registering the corresponding string containing the newly-
characters. available characters.
o Adopt some sort of "variant" approach in which registrants either o Adopt some sort of "variant" approach in which registrants either
obtained labels with both character forms or one of them was obtained labels with both character forms or one of them was
blocked from registration by anyone but the registrant of the blocked from registration by anyone but the registrant of the
other form. other form.
In principle, lookup applications could also compensate for the In principle, lookup applications could also compensate for the
difference in interpretation by looking up the string according to difference in interpretation by looking up the string according to
the interpretation specified in these documents and then, if that the interpretation specified in these documents and then, if that
failed, doing the lookup with the mapping, simulating the IDNA2003 failed, doing the lookup with the mapping, simulating the IDNA2003
skipping to change at page 36, line 9 skipping to change at page 36, line 9
In the protocol as described in these documents, strings containing In the protocol as described in these documents, strings containing
unassigned code points must not be either looked up or registered. unassigned code points must not be either looked up or registered.
There are several reasons for this, with the most important ones There are several reasons for this, with the most important ones
being: being:
o It cannot be known in advance, and with sufficient reliability, o It cannot be known in advance, and with sufficient reliability,
that a code point that was not previously assigned will not be that a code point that was not previously assigned will not be
assigned to a compatibility character or one that would be assigned to a compatibility character or one that would be
otherwise disallowed by the rules in [IDNA2008-Tables]. In otherwise disallowed by the rules in [IDNA2008-Tables]. In
IDNA2003, since there is no direct dependency on NFKC IDNA2003, since there is no direct dependency on NFKC (many of the
(Stringprep's tables are based on NFKC, but IDNA2003 depends only entries in Stringprep's tables are based on NFKC, but IDNA2003
on Stringprep), allocation of a compatibility character might depends only on Stringprep), allocation of a compatibility
produce some odd situations, but it would not be a problem. In character might produce some odd situations, but it would not be a
IDNA2008, where compatibility characters are assigned to problem. In IDNA2008, where compatibility characters are assigned
DISALLOWED unless character-specific exceptions are made, to DISALLOWED unless character-specific exceptions are made,
permitting strings containing unassigned characters to be looked permitting strings containing unassigned characters to be looked
up would permit violating the principle that characters in up would permit violating the principle that characters in
DISALLOWED are not looked up. DISALLOWED are not looked up.
o The Unicode Standard specifies that an unassigned code point o The Unicode Standard specifies that an unassigned code point
normalizes (and, where relevant, case folds) to itself. If the normalizes (and, where relevant, case folds) to itself. If the
code point is later assigned to a character, and particularly if code point is later assigned to a character, and particularly if
the newly-assigned code point has a combining class that the newly-assigned code point has a combining class that
determines its placement relative to other combining characters, determines its placement relative to other combining characters,
it could normalize to some other code point or sequence, creating it could normalize to some other code point or sequence, creating
skipping to change at page 37, line 15 skipping to change at page 37, line 15
obscure characters or archaic scripts. Unfortunately, that does not obscure characters or archaic scripts. Unfortunately, that does not
appear to be a safe assumption for at least two reasons. First, much appear to be a safe assumption for at least two reasons. First, much
the same claim of completeness has been made for earlier versions of the same claim of completeness has been made for earlier versions of
Unicode. The reality is that a script that is obscure to much of the Unicode. The reality is that a script that is obscure to much of the
world may still be very important to those who use it. Cultural and world may still be very important to those who use it. Cultural and
linguistic preservation principles make it inappropriate to declare linguistic preservation principles make it inappropriate to declare
the script of no importance in IDNs. Second, we already have the script of no importance in IDNs. Second, we already have
counterexamples in, e.g., the relationships associated with new Han counterexamples in, e.g., the relationships associated with new Han
characters being added (whether in the BMP or in Unicode Plane 2). characters being added (whether in the BMP or in Unicode Plane 2).
Independent of the technical transition issues identified above, it
can be observed that any addition of characters to an existing script
to make it easier to use or to better accommodate particular
languages may lead to transition issues. Such changes may change the
preferred form for writing a particular string, changes that may be
reflected, e.g., in keyboard transition modules that would
necessarily be different from those for earlier versions of Unicode
where the newer characters may not exist. This creates an inherent
transition problem because attempts to access labels may use either
the old or the new conventions, requiring registry action whether the
older conventions were used in labels or not. The need to consider
transition mechanisms is inherent to evolution of Unicode to better
accommodate writing systems and is independent of how IDNs are
represented in the DNS or how transitions among versions of those
mechanisms occur. The requirement for transitions of this type is
illustrated by the addition of Malayalam Chillu in Unicode 5.1.0.
7.8. Other Compatibility Issues 7.8. Other Compatibility Issues
The 2003 IDNA model includes several odd artifacts of the context in The 2003 IDNA model includes several odd artifacts of the context in
which it was developed. Many, if not all, of these are potential which it was developed. Many, if not all, of these are potential
avenues for exploits, especially if the registration process permits avenues for exploits, especially if the registration process permits
"source" names (names that have not been processed through IDNA and "source" names (names that have not been processed through IDNA and
Nameprep) to be registered. As one example, since the character Nameprep) to be registered. As one example, since the character
Eszett, used in German, is mapped by IDNA2003 into the sequence "ss" Eszett, used in German, is mapped by IDNA2003 into the sequence "ss"
rather than being retained as itself or prohibited, a string rather than being retained as itself or prohibited, a string
containing that character but that is otherwise in ASCII is not containing that character but that is otherwise in ASCII is not
skipping to change at page 38, line 8 skipping to change at page 38, line 26
databases through such channels have already been converted to their databases through such channels have already been converted to their
equivalent ASCII A-label forms. equivalent ASCII A-label forms.
Because of the distinction made between the algorithms for Because of the distinction made between the algorithms for
Registration and Lookup in [IDNA2008-Protocol] (a domain name Registration and Lookup in [IDNA2008-Protocol] (a domain name
containing only ASCII codepoints can not be converted to an A-label), containing only ASCII codepoints can not be converted to an A-label),
there can not be more than one A-label form for any given U-label. there can not be more than one A-label form for any given U-label.
As specified in RFC 2181 [RFC2181], the DNS protocol explicitly As specified in RFC 2181 [RFC2181], the DNS protocol explicitly
allows domain labels to contain octets beyond the ASCII range allows domain labels to contain octets beyond the ASCII range
(0000..007F), and this document does not change that. Note, however, (0000..007F), and this document does not change that. However,
that there is no defined interpretation of octets 0080..00FF as although the interpretation of octets 0080..00FF is well-defined in
characters. If labels containing these octets are returned to the DNS, many application protocols support only ASCII labels and
applications, unpredictable behavior could result. The A-label form, there is no defined interpretation of these non-ASCII octets as
which cannot contain those characters, is the only standard characters and, in particular, no interpretation of case-independent
representation for internationalized labels in the DNS protocol. matching for them (see, e.g., [RFC4343]). If labels containing these
octets are returned to applications, unpredictable behavior could
result. The A-label form, which cannot contain those characters, is
the only standard representation for internationalized labels in the
DNS protocol.
8.2. DNSSEC Authentication of IDN Domain Names 8.2. DNSSEC Authentication of IDN Domain Names
DNS Security (DNSSEC) [RFC2535] is a method for supplying DNS Security (DNSSEC) [RFC2535] is a method for supplying
cryptographic verification information along with DNS messages. cryptographic verification information along with DNS messages.
Public Key Cryptography is used in conjunction with digital Public Key Cryptography is used in conjunction with digital
signatures to provide a means for a requester of domain information signatures to provide a means for a requester of domain information
to authenticate the source of the data. This ensures that it can be to authenticate the source of the data. This ensures that it can be
traced back to a trusted source, either directly or via a chain of traced back to a trusted source, either directly or via a chain of
trust linking the source of the information to the top of the DNS trust linking the source of the information to the top of the DNS
skipping to change at page 41, line 12 skipping to change at page 41, line 38
Karp, John Klensin, Warren Kumari, Lisa Moore, Erik van der Poel, Karp, John Klensin, Warren Kumari, Lisa Moore, Erik van der Poel,
Michel Suignard, and Ken Whistler. We express our thanks to Google Michel Suignard, and Ken Whistler. We express our thanks to Google
for support of that meeting and to the participants for their for support of that meeting and to the participants for their
contributions. contributions.
Useful comments and text on the WG versions of the draft were Useful comments and text on the WG versions of the draft were
received from many participants in the IETF "IDNABIS" WG and a number received from many participants in the IETF "IDNABIS" WG and a number
of document changes resulted from mailing list discussions made by of document changes resulted from mailing list discussions made by
that group. Marcos Sanz provided specific analysis and suggestions that group. Marcos Sanz provided specific analysis and suggestions
that were exceptionally helpful in refining the text, as did Vint that were exceptionally helpful in refining the text, as did Vint
Cerf, Mark Davis, Martin Duerst, Ken Whistler, and Andrew Sullivan. Cerf, Mark Davis, Martin Duerst, Andrew Sullivan, and Ken Whistler.
13. Contributors 13. Contributors
While the listed editor held the pen, this core of this document and While the listed editor held the pen, the core of this document and
the initial WG version represents the joint work and conclusions of the initial WG version represents the joint work and conclusions of
an ad hoc design team consisting of the editor and, in alphabetic an ad hoc design team consisting of the editor and, in alphabetic
order, Harald Alvestrand, Tina Dam, Patrik Faltstrom, and Cary Karp. order, Harald Alvestrand, Tina Dam, Patrik Faltstrom, and Cary Karp.
In addition, there were many specific contributions and helpful In addition, there were many specific contributions and helpful
comments from those listed in the Acknowledgments section and others comments from those listed in the Acknowledgments section and others
who have contributed to the development and use of the IDNA who have contributed to the development and use of the IDNA
protocols. protocols.
14. References 14. References
skipping to change at page 44, line 17 skipping to change at page 44, line 41
Domain Names (IDN) Registration and Administration for Domain Names (IDN) Registration and Administration for
Chinese, Japanese, and Korean", RFC 3743, April 2004. Chinese, Japanese, and Korean", RFC 3743, April 2004.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005. Identifiers (IRIs)", RFC 3987, January 2005.
[RFC4290] Klensin, J., "Suggested Practices for Registration of [RFC4290] Klensin, J., "Suggested Practices for Registration of
Internationalized Domain Names (IDN)", RFC 4290, Internationalized Domain Names (IDN)", RFC 4290,
December 2005. December 2005.
[RFC4343] Eastlake, D., "Domain Name System (DNS) Case Insensitivity
Clarification", RFC 4343, January 2006.
[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, September 2006. (IDNs)", RFC 4690, September 2006.
[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, October 2006. Chinese Domain Names", RFC 4713, October 2006.
[Unicode-Security] [Unicode-Security]
The Unicode Consortium, "Unicode Technical Standard #39: The Unicode Consortium, "Unicode Technical Standard #39:
skipping to change at page 48, line 5 skipping to change at page 48, line 34
moving it to a separate subsection, rather than under "PVALID", moving it to a separate subsection, rather than under "PVALID",
for better parallelism with Tables. Also reflected Mark's for better parallelism with Tables. Also reflected Mark's
comments about the limitations of the approach. comments about the limitations of the approach.
o Added placeholder notes as reminders of where references to the o Added placeholder notes as reminders of where references to the
other documents need Section numbers. More of these will be added other documents need Section numbers. More of these will be added
as needed (feel free to identify relevant places), but the actual as needed (feel free to identify relevant places), but the actual
section numbers will not be inserted until the documents are section numbers will not be inserted until the documents are
completely stable, i.e., on their way to the RFC Editor. completely stable, i.e., on their way to the RFC Editor.
A.9. Version -09
o Small editorial changes to clarify transition possibilities.
o Small clarification to the description of DNS "exact match".
o Added discussion of adding characters to an existing script to the
discussion of unassigned code point transitions in Section 7.7.
o Tightened up the discussion of non-ASCII string processing
(Section 8.1) slightly.
o Removed some placeholders and comments that have been around long
enough to be considered acceptable or that no longer seem
necessary for other reasons.
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. 22 change blocks. 
54 lines changed or deleted 96 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/