< draft-ietf-idnabis-rationale-15.txt   draft-ietf-idnabis-rationale-16.txt >
Network Working Group J. Klensin Network Working Group J. Klensin
Internet-Draft December 15, 2009 Internet-Draft January 7, 2010
Intended status: Informational Intended status: Informational
Expires: June 18, 2010 Expires: July 11, 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-15.txt draft-ietf-idnabis-rationale-16.txt
Abstract Abstract
Several years have passed since the original protocol for Several years have passed since the original protocol for
Internationalized Domain Names (IDNs) was completed and deployed. Internationalized Domain Names (IDNs) was completed and deployed.
During that time, a number of issues have arisen, including the need 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 to update the system to deal with newer versions of Unicode. Some of
these issues require tuning of the existing protocols and the tables these issues require tuning of the existing protocols and the tables
on which they depend. This document provides an overview of a on which they depend. This document provides an overview of a
revised system and provides explanatory material for its components. revised system and provides explanatory material for its components.
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 June 18, 2010. This Internet-Draft will expire on July 11, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
skipping to change at page 4, line 40 skipping to change at page 4, line 40
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 . . . . . . . . . . . . . . . . . . . . . . . 48 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 -15 . . . . . . . . . . . . . . . . . . . . . . . 49 A.15. Version -15 . . . . . . . . . . . . . . . . . . . . . . . 49
A.16. Version -16 . . . . . . . . . . . . . . . . . . . . . . . 49
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 49 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
skipping to change at page 5, line 43 skipping to change at page 5, line 43
to register only exact, valid A-labels, while clients might do some to register only exact, valid A-labels, while clients might do some
mapping to get from otherwise-invalid user input to a valid A-label. mapping to get from otherwise-invalid user input to a valid A-label.
The first version of IDNA was published in 2003 and is referred to The first version of IDNA was published in 2003 and is referred to
here as IDNA2003 to contrast it with the current version, which is here as IDNA2003 to contrast it with the current version, which is
known as IDNA2008 (after the year in which IETF work started on it). known as IDNA2008 (after the year in which IETF work started on it).
IDNA2003 consists of four documents: the IDNA base specification IDNA2003 consists of four documents: the IDNA base specification
[RFC3490], Nameprep [RFC3491], Punycode [RFC3492], and Stringprep [RFC3490], Nameprep [RFC3491], Punycode [RFC3492], and Stringprep
[RFC3454]. The current set of documents, IDNA2008, are not dependent [RFC3454]. The current set of documents, IDNA2008, are not dependent
on any of the IDNA2003 specifications other than the one for Punycode on any of the IDNA2003 specifications other than the one for Punycode
encoding. References to "these specifications" or "these documents" encoding. References to "IDNA2008", "these specifications", or
are to the entire IDNA2008 set listed in [IDNA2008-Defs]. The "these documents" are to the entire IDNA2008 set listed in
characters that are valid in A-labels are identified from rules [IDNA2008-Defs]. The characters that are valid in A-labels are
listed in the Tables document [IDNA2008-Tables], but validity can be identified from rules listed in the Tables document
derived from the Unicode properties of those characters with a very [IDNA2008-Tables], but validity can be derived from the Unicode
few exceptions. properties of those characters with a very few exceptions.
Traditionally, DNS labels are matched case-insensitively Traditionally, DNS labels are matched case-insensitively
[RFC1034][RFC1035]. That convention was preserved in IDNA2003 by a [RFC1034][RFC1035]. That convention was preserved in IDNA2003 by a
case-folding operation that generally maps capital letters into case-folding operation that generally maps capital letters into
lower-case ones. However, if case rules are enforced from one lower-case ones. However, if case rules are enforced from one
language, another language sometimes loses the ability to treat two language, another language sometimes loses the ability to treat two
characters separately. Case-insensitivity is treated slightly characters separately. Case-insensitivity is treated slightly
differently in IDNA2008. differently in IDNA2008.
IDNA2003 used Unicode version 3.2 only. In order to keep up with new IDNA2003 used Unicode version 3.2 only. In order to keep up with new
characters added in new versions of UNICODE, IDNA2008 decouples its characters added in new versions of UNICODE, IDNA2008 decouples its
rules from any particular version of UNICODE. Instead, the rules from any particular version of UNICODE. Instead, the
attributes of new characters in Unicode, supplemented by a small attributes of new characters in Unicode, supplemented by a small
number of exception cases, determine how and whether the characters number of exception cases, determine how and whether the characters
can be used in IDNA labels. can be used in IDNA labels.
This document provides informational context for IDNA2008, including This document provides informational context for IDNA2008, including
terminology, background, and policy discussions. terminology, background, and policy discussions. It contains no
normative material; specifications for conformance to the IDNA2008
protocols appears entirely in the other documents in the series.
1.2. Discussion Forum 1.2. Discussion Forum
[[ RFC Editor: please remove this section. ]] [[ RFC Editor: please remove this section. ]]
IDNA2008 is being discussed in the IETF "idnabis" Working Group and IDNA2008 is being discussed in the IETF "idnabis" Working Group and
on the mailing list idna-update@alvestrand.no on the mailing list idna-update@alvestrand.no
1.3. Terminology 1.3. Terminology
skipping to change at page 7, line 7 skipping to change at page 7, line 7
possible for them to be "words". possible for them to be "words".
This distinction is important because the reasonable goal of an IDN This distinction is important because the reasonable goal of an IDN
effort is not to be able to write the great Klingon (or language of effort is not to be able to write the great Klingon (or language of
one's choice) novel in DNS labels but to be able to form a usefully one's choice) novel in DNS labels but to be able to form a usefully
broad range of mnemonics in ways that are as natural as possible in a broad range of mnemonics in ways that are as natural as possible in a
very broad range of scripts. very broad range of scripts.
1.3.2. New Terminology and Restrictions 1.3.2. New Terminology and Restrictions
These documents introduce new terminology, and precise definitions IDNA2008 introduces new terminology. Precise definitions are
(in [IDNA2008-Defs]), for the terms "U-label", "A-Label", LDH-label provided (in [IDNA2008-Defs]), for the terms "U-label", "A-Label",
(to which all valid pre-IDNA host names conformed), Reserved-LDH- LDH-label (to which all valid pre-IDNA host names conformed),
label (R-LDH-label), XN-label, Fake-A-Label, and Non-Reserved-LDH- Reserved-LDH-label (R-LDH-label), XN-label, Fake-A-Label, and Non-
label (NR-LDH-label). Reserved-LDH-label (NR-LDH-label).
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 also illustrated in Figure 1 of the Definitions These definitions are also 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
skipping to change at page 10, line 29 skipping to change at page 10, line 29
in display, transit and storage, which should aid comprehensibility in display, transit and storage, which should aid comprehensibility
and predictability. A careful look at pre-processing raises issues and predictability. A careful look at pre-processing raises issues
about what that pre-processing should do and at what point pre- about what that pre-processing should do and at what point pre-
processing becomes harmful, how universally consistent pre-processing processing becomes harmful, how universally consistent pre-processing
algorithms can be, and how to be compatible with labels prepared in a algorithms can be, and how to be compatible with labels prepared in a
IDNA2003 context. Those issues are discussed in Section 6 and in the IDNA2003 context. Those issues are discussed in Section 6 and in the
separate document [IDNA2008-Mapping]. separate document [IDNA2008-Mapping].
2. Processing in IDNA2008 2. Processing in IDNA2008
These specifications separate Domain Name Registration and Lookup in IDNA2008 separates Domain Name Registration and Lookup in the
the protocol specification. Although most steps in the two processes protocol specification. Although most steps in the two processes are
are similar, the separation reflects current practice in which per- similar, the separation reflects current practice in which per-
registry (DNS zone) restrictions and special processing are applied registry (DNS zone) restrictions and special processing are applied
at registration time but not during lookup. Another significant at registration time but not during lookup. Another significant
benefit is that separation facilitates incremental addition of benefit is that separation facilitates incremental addition of
permitted character groups to avoid freezing on one particular permitted character groups to avoid freezing on one particular
version of Unicode. version of Unicode.
The actual registration and lookup protocols for IDNA2008 are The actual registration and lookup protocols for IDNA2008 are
specified in [IDNA2008-Protocol]. specified in [IDNA2008-Protocol].
3. Permitted Characters: An Inclusion List 3. Permitted Characters: An Inclusion List
skipping to change at page 18, line 17 skipping to change at page 18, line 17
whatever character encoding and escape mechanism the protocol or whatever character encoding and escape mechanism the protocol or
document format uses at that place. This provision is intended to document format uses at that place. This provision is intended to
prevent situations in which, e.g., UTF-8 domain names appear embedded prevent situations in which, e.g., UTF-8 domain names appear embedded
in text that is otherwise in some other character coding. in text that is otherwise in some other character coding.
All protocols that use domain name slots (See Section 2.3.1.6 in All protocols that use domain name slots (See Section 2.3.1.6 in
[IDNA2008-Defs]) already have the capacity for handling domain names [IDNA2008-Defs]) already have the capacity for handling domain names
in the ASCII charset. Thus, A-labels can inherently be handled by in the ASCII charset. Thus, A-labels can inherently be handled by
those protocols. those protocols.
These documents do not specify required mappings between one IDNA2008 does not specify required mappings between one character or
character or code point and others. An extended discussion of code point and others. An extended discussion of mapping issues
mapping issues occurs in Section 6 and specific recommendations occurs in Section 6 and specific recommendations appear in
appear in [IDNA2008-Mapping]. In general, IDNA2008 prohibits [IDNA2008-Mapping]. In general, IDNA2008 prohibits characters that
characters that would be mapped to others by normalization or other would be mapped to others by normalization or other rules. As
rules. As examples, while mathematical characters based on Latin examples, while mathematical characters based on Latin ones are
ones are accepted as input to IDNA2003, they are prohibited in accepted as input to IDNA2003, they are prohibited in IDNA2008.
IDNA2008. Similarly, upper-case characters, double-width characters, Similarly, upper-case characters, double-width characters, and other
and other variations are prohibited as IDNA input although mapping variations are prohibited as IDNA input although mapping them as
them as needed in user interfaces is strongly encouraged. needed in user interfaces is strongly encouraged.
Since the rules in [IDNA2008-Tables] have the effect that only Since the rules in [IDNA2008-Tables] have the effect that only
strings that are not transformed by NFKC are valid, if an application strings that are not transformed by NFKC are valid, if an application
chooses to perform NFKC normalization before lookup, that operation chooses to perform NFKC normalization before lookup, that operation
is safe since this will never make the application unable to look up is safe since this will never make the application unable to look up
any valid string. However, as discussed above, the application any valid string. However, as discussed above, the application
cannot guarantee that any other application will perform that cannot guarantee that any other application will perform that
mapping, so it should be used only with caution and for informed mapping, so it should be used only with caution and for informed
users. users.
skipping to change at page 21, line 9 skipping to change at page 21, line 9
Some of the ligatures that have explicit code points in Unicode were Some of the ligatures that have explicit code points in Unicode were
given special handling in IDNA2003 and now pose additional problems given special handling in IDNA2003 and now pose additional problems
in transition. See Section 7.2. in transition. See Section 7.2.
Additional cases with alphabets written right to left are described Additional cases with alphabets written right to left are described
in Section 4.5. in Section 4.5.
Matching and comparison algorithm selection often requires Matching and comparison algorithm selection often requires
information about the language being used, context, or both -- information about the language being used, context, or both --
information that is not available to IDNA or the DNS. Consequently, information that is not available to IDNA or the DNS. Consequently,
these specifications make no attempt to treat combined characters in IDNA2008 makes no attempt to treat combined characters in any special
any special way. A registry that is aware of the language context in way. A registry that is aware of the language context in which
which labels are to be registered, and where that language sometimes labels are to be registered, and where that language sometimes (or
(or always) treats the two- character sequences as equivalent to the always) treats the two- character sequences as equivalent to the
combined form, should give serious consideration to applying a combined form, should give serious consideration to applying a
"variant" model [RFC3743][RFC4290], or to prohibiting registration of "variant" model [RFC3743][RFC4290], or to prohibiting registration of
one of the forms entirely, to reduce the opportunities for user one of the forms entirely, to reduce the opportunities for user
confusion and fraud that would result from the related strings being confusion and fraud that would result from the related strings being
registered to different parties. registered to different parties.
4.4. Case Mapping and Related Issues 4.4. Case Mapping and Related Issues
In the DNS, ASCII letters are stored with their case preserved. In the DNS, ASCII letters are stored with their case preserved.
Matching during the query process is case-independent, but none of Matching during the query process is case-independent, but none of
skipping to change at page 21, line 35 skipping to change at page 21, line 35
have created DNS labels by catenating words (or parts of words) to have created DNS labels by catenating words (or parts of words) to
form labels, case has often been used to distinguish among components form labels, case has often been used to distinguish among components
and make the labels more memorable. and make the labels more memorable.
Since DNS servers do not get involved in parsing IDNs, they cannot do Since DNS servers do not get involved in parsing IDNs, they cannot do
case-independent matching. Thus, keeping the cases separate in case-independent matching. Thus, keeping the cases separate in
lookup or registration, and doing matching at the server, is not lookup or registration, and doing matching at the server, is not
feasible with IDNA or any similar approach. Case-matching must be feasible with IDNA or any similar approach. Case-matching must be
done, if desired, by IDN clients even though it wasn't done by ASCII- done, if desired, by IDN clients even though it wasn't done by ASCII-
only DNS clients. That situation was recognized in IDNA2003 and only DNS clients. That situation was recognized in IDNA2003 and
nothing in these specifications fundamentally changes it or could do nothing in IDNA2008 fundamentally changes it or could do so. In
so. In IDNA2003, all characters are case-folded and mapped by IDNA2003, all characters are case-folded and mapped by clients in a
clients in a standardized step. standardized step.
Some characters do not have upper case forms. For example the Some characters do not have upper case forms. For example the
Unicode case folding operation maps Greek Final Form Sigma (U+03C2) Unicode case folding operation maps Greek Final Form Sigma (U+03C2)
to the medial form (U+03C3) and maps Eszett (German Sharp S, U+00DF) to the medial form (U+03C3) and maps Eszett (German Sharp S, U+00DF)
to "ss". Neither of these mappings is reversible because the upper to "ss". Neither of these mappings is reversible because the upper
case of U+03C3 is the Upper Case Sigma (U+03A3) and "ss" is an ASCII case of U+03C3 is the Upper Case Sigma (U+03A3) and "ss" is an ASCII
string. IDNA2008 permits, at the risk of some incompatibility, string. IDNA2008 permits, at the risk of some incompatibility,
slightly more flexibility in this area by avoiding case folding and slightly more flexibility in this area by avoiding case folding and
treating these characters as themselves. Approaches to handling one- treating these characters as themselves. Approaches to handling one-
way mappings are discussed in Section 7.2. way mappings are discussed in Section 7.2.
skipping to change at page 26, line 50 skipping to change at page 26, line 50
Any label registered in a DNS zone must be validated -- i.e., the Any label registered in a DNS zone must be validated -- i.e., the
criteria for that label must be met -- in order for applications to criteria for that label must be met -- in order for applications to
work as intended. This principle is not new. For example, since the work as intended. This principle is not new. For example, since the
DNS was first deployed, zone administrators have been expected to DNS was first deployed, zone administrators have been expected to
verify that names meet "hostname" requirements [RFC0952] where those verify that names meet "hostname" requirements [RFC0952] where those
requirements are imposed by the expected applications. Other requirements are imposed by the expected applications. Other
applications contexts, such as the later addition of special service applications contexts, such as the later addition of special service
location formats [RFC2782] imposed new requirements on zone location formats [RFC2782] imposed new requirements on zone
administrators. For zones that will contain IDNs, support for administrators. For zones that will contain IDNs, support for
Unicode version-independence requires restrictions on all strings Unicode version-independence requires restrictions on all strings
placed in the zone. In particular, for such zones: placed in the zone. In particular, for such zones (the exact rules
appear in the Protocol Document, Section 4 [IDNA2008-Protocol]):
o Any label that appears to be an A-label, i.e., any label that o Any label that appears to be an A-label, i.e., any label that
starts in "xn--", must be valid under IDNA, i.e., they must be starts in "xn--", must be valid under IDNA, i.e., they must be
valid A-labels, as discussed in Section 2 above. valid A-labels, as discussed in Section 2 above.
o The Unicode tables (i.e., tables of code points, character o The Unicode tables (i.e., tables of code points, character
classes, and properties) and IDNA tables (i.e., tables of classes, and properties) and IDNA tables (i.e., tables of
contextual rules such as those that appear in the Tables contextual rules such as those that appear in the Tables
document), must be consistent on the systems performing or document), must be consistent on the systems performing or
validating labels to be registered. Note that this does not validating labels to be registered. Note that this does not
skipping to change at page 27, line 32 skipping to change at page 27, line 32
authorized characters, until and unless it wishes to support them. authorized characters, until and unless it wishes to support them.
The zone administrator is responsible for verifying validity for IDNA The zone administrator is responsible for verifying validity for IDNA
as well as its local policies -- a more extensive set of checks than as well as its local policies -- a more extensive set of checks than
are required for looking up the labels. Systems looking up or are required for looking up the labels. Systems looking up or
resolving DNS labels, especially IDN DNS labels, must be able to resolving DNS labels, especially IDN DNS labels, must be able to
assume that applicable registration rules were followed for names assume that applicable registration rules were followed for names
entered into the DNS. entered into the DNS.
7.1.3. Labels in Lookup 7.1.3. Labels in Lookup
Anyone looking up a label in a DNS zone is required to Any application processing a label through IDNA so it can be looked
up in a DNS zone is required to (the exact rules appear in the
Protocol Document, Section 5 [IDNA2008-Protocol])
o Maintain IDNA and Unicode tables that are consistent with regard o Maintain IDNA and Unicode tables that are consistent with regard
to versions, i.e., unless the application actually executes the to versions, i.e., unless the application actually executes the
classification rules in [IDNA2008-Tables], its IDNA tables must be classification rules in [IDNA2008-Tables], its IDNA tables must be
derived from the version of Unicode that is supported more derived from the version of Unicode that is supported more
generally on the system. As with registration, the tables need generally on the system. As with registration, the tables need
not reflect the latest version of Unicode but they must be not reflect the latest version of Unicode but they must be
consistent. consistent.
o Validate the characters in labels to be looked up only to the o Validate the characters in labels to be looked up only to the
skipping to change at page 35, line 44 skipping to change at page 35, line 44
languages and scripts which would be treated like any other language languages and scripts which would be treated like any other language
characters; the two should not be confused. characters; the two should not be confused.
7.7. Migration Between Unicode Versions: Unassigned Code Points 7.7. Migration Between Unicode Versions: Unassigned Code Points
In IDNA2003, labels containing unassigned code points are looked up In IDNA2003, labels containing unassigned code points are looked up
on the assumption that, if they appear in labels and can be mapped on the assumption that, if they appear in labels and can be mapped
and then resolved, the relevant standards must have changed and the and then resolved, the relevant standards must have changed and the
registry has properly allocated only assigned values. registry has properly allocated only assigned values.
In the protocol described in these documents, strings containing In the IDNA2008 protocol, strings containing unassigned code points
unassigned code points must not be either looked up or registered. must not be either looked up or registered. In summary, the status
In summary, the status of an unassigned character with regard to the of an unassigned character with regard to the DISALLOWED, PROTOCOL-
DISALLOWED, PROTOCOL-VALID, and CONTEXTUAL RULE REQUIRED categories VALID, and CONTEXTUAL RULE REQUIRED categories cannot be evaluated
cannot be evaluated until a character is actually assigned and known. until a character is actually assigned and known. There are several
There are several reasons for this, with the most important ones reasons for this, with the most important ones being:
being:
o Tests involving the context of characters (e.g., some characters o Tests involving the context of characters (e.g., some characters
being permitted only adjacent to others of specific types) and being permitted only adjacent to others of specific types) and
integrity tests on complete labels are needed. Unassigned code integrity tests on complete labels are needed. Unassigned code
points cannot be permitted because one cannot determine whether points cannot be permitted because one cannot determine whether
particular code points will require contextual rules (and what particular code points will require contextual rules (and what
those rules should be) before characters are assigned to them and those rules should be) before characters are assigned to them and
the properties of those characters fully understood. the properties of those characters fully understood.
o It cannot be known in advance, and with sufficient reliability, o It cannot be known in advance, and with sufficient reliability,
skipping to change at page 39, line 42 skipping to change at page 39, line 42
10.3. IANA Repository of IDN Practices of TLDs 10.3. IANA Repository of IDN Practices of TLDs
This registry, historically described as the "IANA Language Character This registry, historically described as the "IANA Language Character
Set Registry" or "IANA Script Registry" (both somewhat misleading Set Registry" or "IANA Script Registry" (both somewhat misleading
terms) is maintained by IANA at the request of ICANN. It is used to terms) is maintained by IANA at the request of ICANN. It is used to
provide a central documentation repository of the IDN policies used provide a central documentation repository of the IDN policies used
by top level domain (TLD) registries who volunteer to contribute to by top level domain (TLD) registries who volunteer to contribute to
it and is used in conjunction with ICANN Guidelines for IDN use. it and is used in conjunction with ICANN Guidelines for IDN use.
It is not an IETF-managed registry and, while the protocol changes It is not an IETF-managed registry and, while the protocol changes
specified here may call for some revisions to the tables, these specified here may call for some revisions to the tables, IDNA2008
specifications have no direct effect on that registry and no IANA has no direct effect on that registry and no IANA action is required
action is required as a result. as a result.
11. Security Considerations 11. Security Considerations
11.1. General Security Issues with IDNA 11.1. General Security Issues with IDNA
This document is purely explanatory and informational and This document is purely explanatory and informational and
consequently introduces no new security issues. It would, of course, consequently introduces no new security issues. It would, of course,
be a poor idea for someone to try to implement from it; such an be a poor idea for someone to try to implement from it; such an
attempt would almost certainly lead to interoperability problems and attempt would almost certainly lead to interoperability problems and
might lead to security ones. A discussion of security issues with might lead to security ones. A discussion of security issues with
skipping to change at page 50, line 9 skipping to change at page 50, line 9
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 A.15. Version -15
o Rewrote and expanded the "transition" material of Section 7.2. o Rewrote and expanded the "transition" material of Section 7.2.
A.16. Version -16
This version contains changes made at IESG request during their
review. Some additional comments were logged during or immediately
before the 7 January 2010 teleconference, so this is not the final
I-D version.
o Altered use of "these documents" and "these specifications" back
to "IDNA2008", undoing the change made in Appendix A.6. The
convolutions became ambiguous in places.
o Added a sentence to the Introduction to make the non-normative
status of this document even more clear and added references to
7.1.2 and 7.1.3 to point to the more formal definitions.
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. 18 change blocks. 
49 lines changed or deleted 69 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/