draft-ietf-idnabis-protocol-16.txt   draft-ietf-idnabis-protocol-17.txt 
Network Working Group J. Klensin Network Working Group J. Klensin
Internet-Draft September 13, 2009 Internet-Draft October 25, 2009
Obsoletes: 3490, 3491 Obsoletes: 3490, 3491
(if approved) (if approved)
Updates: 3492 (if approved) Updates: 3492 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: March 17, 2010 Expires: April 28, 2010
Internationalized Domain Names in Applications (IDNA): Protocol Internationalized Domain Names in Applications (IDNA): Protocol
draft-ietf-idnabis-protocol-16.txt draft-ietf-idnabis-protocol-17.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 45 skipping to change at page 1, line 45
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 March 17, 2010. This Internet-Draft will expire on April 28, 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 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
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. DNS Resource Records . . . . . . . . . . . . . . . . . 7 3.2.1. DNS Resource Records . . . . . . . . . . . . . . . . . 7
3.2.2. Non-domain-name Data Types Stored in the DNS . . . . . 7 3.2.2. Non-domain-name Data Types Stored in the DNS . . . . . 7
4. Registration Protocol . . . . . . . . . . . . . . . . . . . . 7 4. Registration Protocol . . . . . . . . . . . . . . . . . . . . 7
4.1. Input to IDNA Registration . . . . . . . . . . . . . . . . 8 4.1. Input to IDNA Registration . . . . . . . . . . . . . . . . 8
4.2. Permitted Character and Label Validation . . . . . . . . . 8 4.2. Permitted Character and Label Validation . . . . . . . . . 8
4.2.1. Input Format . . . . . . . . . . . . . . . . . . . . . 8 4.2.1. Input Format . . . . . . . . . . . . . . . . . . . . . 8
4.2.2. Rejection of Characters that are not Permitted . . . . 9 4.2.2. Rejection of Characters that are not Permitted . . . . 9
4.2.3. Label Validation . . . . . . . . . . . . . . . . . . . 9 4.2.3. Label Validation . . . . . . . . . . . . . . . . . . . 9
4.2.4. Registration Validation Summary . . . . . . . . . . . 9 4.2.4. Registration Validation Requirements . . . . . . . . . 9
4.3. Registry Restrictions . . . . . . . . . . . . . . . . . . 10 4.3. Registry Restrictions . . . . . . . . . . . . . . . . . . 10
4.4. Punycode Conversion . . . . . . . . . . . . . . . . . . . 10 4.4. Punycode Conversion . . . . . . . . . . . . . . . . . . . 10
4.5. Insertion in the Zone . . . . . . . . . . . . . . . . . . 10 4.5. Insertion in the Zone . . . . . . . . . . . . . . . . . . 11
5. Domain Name Lookup Protocol . . . . . . . . . . . . . . . . . 11 5. Domain Name Lookup Protocol . . . . . . . . . . . . . . . . . 11
5.1. Label String Input . . . . . . . . . . . . . . . . . . . . 11 5.1. Label String Input . . . . . . . . . . . . . . . . . . . . 11
5.2. Conversion to Unicode . . . . . . . . . . . . . . . . . . 11 5.2. Conversion to Unicode . . . . . . . . . . . . . . . . . . 11
5.3. A-label Input . . . . . . . . . . . . . . . . . . . . . . 11 5.3. A-label Input . . . . . . . . . . . . . . . . . . . . . . 11
5.4. Validation and Character List Testing . . . . . . . . . . 12 5.4. Validation and Character List Testing . . . . . . . . . . 12
5.5. Punycode Conversion . . . . . . . . . . . . . . . . . . . 13 5.5. Punycode Conversion . . . . . . . . . . . . . . . . . . . 13
5.6. DNS Name Resolution . . . . . . . . . . . . . . . . . . . 13 5.6. DNS Name Resolution . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Summary of Major Changes from IDNA2003 . . . . . . . 17 Appendix A. Summary of Major Changes from IDNA2003 . . . . . . . 18
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18
B.1. Changes between Version -00 and -01 of B.1. Changes between Version -00 and -01 of
draft-ietf-idnabis-protocol . . . . . . . . . . . . . . . 18 draft-ietf-idnabis-protocol . . . . . . . . . . . . . . . 18
B.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 18 B.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 19
B.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 19 B.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 19
B.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 19 B.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 19
B.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 19 B.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 19
B.6. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 19 B.6. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 20
B.7. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 20 B.7. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 20
B.8. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 20 B.8. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 20
B.9. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 20 B.9. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 21
B.10. Version -10 . . . . . . . . . . . . . . . . . . . . . . . 21 B.10. Version -10 . . . . . . . . . . . . . . . . . . . . . . . 21
B.11. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 21 B.11. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 21
B.12. Version -12 . . . . . . . . . . . . . . . . . . . . . . . 21 B.12. Version -12 . . . . . . . . . . . . . . . . . . . . . . . 22
B.13. Version -13 . . . . . . . . . . . . . . . . . . . . . . . 22 B.13. Version -13 . . . . . . . . . . . . . . . . . . . . . . . 22
B.14. Version -14 . . . . . . . . . . . . . . . . . . . . . . . 22 B.14. Version -14 . . . . . . . . . . . . . . . . . . . . . . . 22
B.15. Version -15 . . . . . . . . . . . . . . . . . . . . . . . 22 B.15. Version -15 . . . . . . . . . . . . . . . . . . . . . . . 23
B.16. Version -16 . . . . . . . . . . . . . . . . . . . . . . . 23 B.16. Version -16 . . . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 B.17. Version -17 . . . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
This document supplies the protocol definition for internationalized This document supplies the protocol definition for internationalized
domain names. Essential definitions and terminology for domain names. Essential definitions and terminology for
understanding this document and a road map of the collection of understanding this document and a road map of the collection of
documents that make up IDNA2008 appear in [IDNA2008-Defs]. documents that make up IDNA2008 appear in [IDNA2008-Defs].
Appendix A discusses the relationship between this specification and Appendix A discusses the relationship between this specification and
the earlier version of IDNA (referred to here as "IDNA2003"). The the earlier version of IDNA (referred to here as "IDNA2003"). The
rationale for these changes, along with considerable explanatory rationale for these changes, along with considerable explanatory
skipping to change at page 5, line 25 skipping to change at page 5, line 25
provided in another document, [IDNA2008-Rationale]. provided in another document, [IDNA2008-Rationale].
IDNA works by allowing applications to use certain ASCII string IDNA works by allowing applications to use certain ASCII string
labels (beginning with a special prefix) to represent non-ASCII name labels (beginning with a special prefix) to represent non-ASCII name
labels. Lower-layer protocols need not be aware of this; therefore labels. Lower-layer protocols need not be aware of this; therefore
IDNA does not change any infrastructure. In particular, IDNA does IDNA does not change any infrastructure. In particular, IDNA does
not depend on any changes to DNS servers, resolvers, or DNS protocol not depend on any changes to DNS servers, resolvers, or DNS protocol
elements, because the ASCII name service provided by the existing DNS elements, because the ASCII name service provided by the existing DNS
can be used for IDNA. can be used for IDNA.
IDNA applies only to DNS labels. The base DNS standards [RFC1034] IDNA applies only to a specific subset of DNS labels. The base DNS
[RFC1035] and their various updates specify how to combine labels standards [RFC1034] [RFC1035] and their various updates specify how
into fully-qualified domain names and parse labels out of those to combine labels into fully-qualified domain names and parse labels
names. out of those names.
This document describes two separate protocols, one for IDN This document describes two separate protocols, one for IDN
registration (Section 4) and one for IDN lookup (Section 5). These registration (Section 4) and one for IDN lookup (Section 5). These
two protocols share some terminology, reference data and operations. two protocols share some terminology, reference data and operations.
1.1. Discussion Forum 1.1. Discussion Forum
[[ RFC Editor: please remove this section. ]] [[ RFC Editor: please remove this section. ]]
This work is being discussed in the IETF IDNABIS WG and on the This work is being discussed in the IETF IDNABIS WG and on the
mailing list idna-update@alvestrand.no mailing list idna-update@alvestrand.no
2. Terminology 2. Terminology
Terminology used as part of the definition of IDNA appears in Terminology used as part of the definition of IDNA appears in
[IDNA2008-Defs]. It is worth noting that some of this terminology [IDNA2008-Defs]. It is worth noting that some of this terminology
overlaps with, and is consistent with, that used , but also in overlaps with, and is consistent with, that used in Unicode or other
Unicode or other character set standards and the DNS. Readers of character set standards and the DNS. Readers of this document are
this document are assumed to be familiar with [IDNA2008-Defs] and assumed to be familiar with [IDNA2008-Defs] and with the DNS-specific
with the DNS-specific terminology in RFC 1034 [RFC1034]. terminology in RFC 1034 [RFC1034].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
3. Requirements and Applicability 3. Requirements and Applicability
3.1. Requirements 3.1. Requirements
IDNA makes the following requirements: IDNA makes the following requirements:
1. Whenever a domain name is put into an IDN-unaware domain name 1. Whenever a domain name is put into an IDN-unaware domain name
slot (see Section 2 and [IDNA2008-Defs]), it MUST contain only slot (see Section 2 and [IDNA2008-Defs]), it MUST contain only
ASCII characters (i.e., must be either an A-label or an NR-LDH- ASCII characters (i.e., its labels must be either A-labels or NR-
label), unless the DNS application is not subject to historical LDH-labels), unless the DNS application is not subject to
recommendations for "hostname"-style names (see [RFC1034] and historical recommendations for "hostname"-style names (see
Section 3.2.1). [RFC1034] and Section 3.2.1).
2. Labels MUST be compared using equivalent forms: either both 2. Labels MUST be compared using equivalent forms: either both
A-Label forms or both U-Label forms. Because A-labels and A-Label forms or both U-Label forms. Because A-labels and
U-labels can be transformed into each other without loss of U-labels can be transformed into each other without loss of
information, these comparisons are equivalent. A pair of information, these comparisons are equivalent. A pair of
A-labels MUST be compared as case-insensitive ASCII (as with all A-labels MUST be compared as case-insensitive ASCII (as with all
comparisons of ASCII DNS labels). U-labels must be compared comparisons of ASCII DNS labels). U-labels must be compared
as-is, without case-folding or other intermediate steps. Note as-is, without case-folding or other intermediate steps. Note
that it is not necessary to validate labels in order to compare that it is not necessary to validate labels in order to compare
them and that successful comparison does not imply validity. In them and that successful comparison does not imply validity. In
skipping to change at page 6, line 50 skipping to change at page 6, line 50
to domain name slots which do not use the Letter/Digit/Hyphen (LDH) to domain name slots which do not use the Letter/Digit/Hyphen (LDH)
syntax rules. syntax rules.
Because IDNA uses the DNS, IDNA applies to many protocols that were Because IDNA uses the DNS, IDNA applies to many protocols that were
specified before it was designed. IDNs occupying domain name slots specified before it was designed. IDNs occupying domain name slots
in those older protocols MUST be in A-label form until and unless in those older protocols MUST be in A-label form until and unless
those protocols and their implementations are explicitly upgraded to those protocols and their implementations are explicitly upgraded to
be aware of IDNs. IDNs actually appearing in DNS queries or be aware of IDNs. IDNs actually appearing in DNS queries or
responses MUST be A-labels. responses MUST be A-labels.
IDNA is not defined for extended label types (see RFC 2671, Section 3 IDNA-aware protocols and implementations MAY accept U-labels,
A-labels, or both as those particular protocols specify.
IDNA is not defined for extended label types (see RFC 2671, Section 3
[RFC2671]). [RFC2671]).
3.2.1. DNS Resource Records 3.2.1. DNS Resource Records
IDNA applies only to domain names in the NAME and RDATA fields of DNS IDNA applies only to domain names in the NAME and RDATA fields of DNS
resource records whose CLASS is IN. See RFC 1034 [RFC1034] for resource records whose CLASS is IN. See RFC 1035 [RFC1035] for
precise definitions of these terms. precise definitions of these terms.
The application of IDNA to DNS resource records depends entirely on The application of IDNA to DNS resource records depends entirely on
the CLASS of the record, and not on the TYPE except as noted below. the CLASS of the record, and not on the TYPE except as noted below.
This will remain true, even as new types are defined, unless a new This will remain true, even as new types are defined, unless a new
type defines type-specific rules. Special naming conventions for SRV type defines type-specific rules. Special naming conventions for SRV
records (and "underscore labels" more generally) are incompatible records (and "underscore labels" more generally) are incompatible
with IDNA coding as discussed in [IDNA2008-Defs], especially Section with IDNA coding as discussed in [IDNA2008-Defs], especially Section
2.3.2.3. Of course, underscore labels may be part of a domain that 2.3.2.3. Of course, underscore labels may be part of a domain that
uses IDN labels at higher levels in the tree. uses IDN labels at higher levels in the tree.
skipping to change at page 7, line 47 skipping to change at page 7, line 49
format of the SOA RR. format of the SOA RR.
4. Registration Protocol 4. Registration Protocol
This section defines the model for registering an IDN. The model is This section defines the model for registering an IDN. The model is
implementation independent; any sequence of steps that produces implementation independent; any sequence of steps that produces
exactly the same result for all labels is considered a valid exactly the same result for all labels is considered a valid
implementation. implementation.
Note that, while the registration (this section) and lookup protocols Note that, while the registration (this section) and lookup protocols
(Section 5) are very similar in most respects, they not identical and (Section 5) are very similar in most respects, they are not identical
implementers should carefully follow the steps described in this and implementers should carefully follow the steps described in this
specification. specification.
4.1. Input to IDNA Registration 4.1. Input to IDNA Registration
Registration processes, especially processing by entities (often Registration processes, especially processing by entities (often
called "registrars") who deal with registrants before the request called "registrars") who deal with registrants before the request
actually reaches the zone manager ("registry") are outside the scope actually reaches the zone manager ("registry") are outside the scope
of this definition and may differ significantly depending on local of this definition and may differ significantly depending on local
needs. By the time a string enters the IDNA registration process as needs. By the time a string enters the IDNA registration process as
described in this specification, it MUST be in Unicode and in described in this specification, it MUST be in Unicode and in
skipping to change at page 8, line 47 skipping to change at page 8, line 48
step in Section 4.4 matches the one provided as input. In addition, step in Section 4.4 matches the one provided as input. In addition,
the U-label that was provided as input and the one obtained by the U-label that was provided as input and the one obtained by
conversion of the A-label MUST match exactly. If, for some reason, conversion of the A-label MUST match exactly. If, for some reason,
these tests fail, the registration MUST be rejected. these tests fail, the registration MUST be rejected.
If only an A-label was provided and the conversion to a U-label is If only an A-label was provided and the conversion to a U-label is
not performed, the registry MUST still verify that the A-label is not performed, the registry MUST still verify that the A-label is
superficially valid, i.e., that it does not violate any of the rules superficially valid, i.e., that it does not violate any of the rules
of Punycode [RFC3492] encoding such as the prohibition on trailing of Punycode [RFC3492] encoding such as the prohibition on trailing
hyphen-minus, appearance of non-basic characters before the hyphen-minus, appearance of non-basic characters before the
delimiter, and so on. Fake A-labels, i.e., invalid strings that delimiter, and so on. Strings that appear to be A-labels (e.g., they
appear to be A-labels but are not, MUST NOT be placed in DNS zones start with "xn--") and strings that are supplied to the registry in a
that support IDNA. context (such as a field in a form to be filled out) reserved for
A-labels, but that are not valid A-labels as described in this
paragraph, MUST NOT be placed in DNS zones that support IDNA.
4.2.2. Rejection of Characters that are not Permitted 4.2.2. Rejection of Characters that are not Permitted
The candidate Unicode string MUST NOT contain characters that appear The candidate Unicode string MUST NOT contain characters that appear
in the "DISALLOWED" and "UNASSIGNED" lists specified in in the "DISALLOWED" and "UNASSIGNED" lists specified in
[IDNA2008-Tables]. [IDNA2008-Tables].
4.2.3. Label Validation 4.2.3. Label Validation
The proposed label (in the form of a Unicode string, i.e., a string The proposed label (in the form of a Unicode string, i.e., a string
skipping to change at page 9, line 46 skipping to change at page 9, line 47
and CONTEXTO in [IDNA2008-Tables] MUST have a non-null rule. If such and CONTEXTO in [IDNA2008-Tables] MUST have a non-null rule. If such
a code-point is missing a rule, it is invalid. If the rule exists a code-point is missing a rule, it is invalid. If the rule exists
but the result of applying the rule is negative or inconclusive, the but the result of applying the rule is negative or inconclusive, the
proposed label is invalid. proposed label is invalid.
4.2.3.4. Labels Containing Characters Written Right to Left 4.2.3.4. Labels Containing Characters Written Right to Left
If the proposed label contains any characters that are written from If the proposed label contains any characters that are written from
right to left it MUST meet the BIDI criteria [IDNA2008-BIDI]. right to left it MUST meet the BIDI criteria [IDNA2008-BIDI].
4.2.4. Registration Validation Summary 4.2.4. Registration Validation Requirements
Strings that contain at least one non-ASCII character, have been Strings that contain at least one non-ASCII character, have been
produced by the steps above, whose contents pass all of the tests in produced by the steps above, whose contents pass all of the tests in
Section 4.2, and are 63 or fewer characters long in ACE form (see Section 4.2.3, and are 63 or fewer characters long in ACE form (see
Section 4.4), are U-labels. Section 4.4), are U-labels.
To summarize, tests are made in Section 4.2 for invalid characters, To summarize, tests are made in Section 4.2 for invalid characters,
invalid combinations of characters, for labels that are invalid even invalid combinations of characters, for labels that are invalid even
if the characters they contain are valid individually, and for labels if the characters they contain are valid individually, and for labels
that do not conform to the restrictions for strings containing right that do not conform to the restrictions for strings containing right
to left characters. to left characters.
4.3. Registry Restrictions 4.3. Registry Restrictions
skipping to change at page 10, line 44 skipping to change at page 10, line 45
string must, of course, conform to the length limits imposed by the string must, of course, conform to the length limits imposed by the
DNS. This document does not update or alter the Punycode algorithm DNS. This document does not update or alter the Punycode algorithm
specified in RFC 3492 in any way. That document does make a non- specified in RFC 3492 in any way. That document does make a non-
normative reference to the information about the value and normative reference to the information about the value and
construction of the ACE prefix that appears "in RFC 3490 or Nameprep construction of the ACE prefix that appears "in RFC 3490 or Nameprep
[RFC3491]". For consistency and reader convenience, IDNA2008 [RFC3491]". For consistency and reader convenience, IDNA2008
effectively updates that reference to point to this document. That effectively updates that reference to point to this document. That
change does not alter the prefix itself. The prefix, "xn--", is the change does not alter the prefix itself. The prefix, "xn--", is the
same in both sets of documents. same in both sets of documents.
The failure conditions identified in the Punycode encoding procedure With the exception of the maximum string length test on Punycode
cannot occur if the input is a U-label as determined by the steps output, the failure conditions identified in the Punycode encoding
above. procedure cannot occur if the input is a U-label as determined by the
steps in Section 4.1 through Section 4.3 above.
4.5. Insertion in the Zone 4.5. Insertion in the Zone
The label is registered in the DNS by inserting the A-label into a The label is registered in the DNS by inserting the A-label into a
zone. zone.
5. Domain Name Lookup Protocol 5. Domain Name Lookup Protocol
Lookup is different from registration and different tests are applied Lookup is different from registration and different tests are applied
on the client. Although some validity checks are necessary to avoid on the client. Although some validity checks are necessary to avoid
skipping to change at page 11, line 39 skipping to change at page 11, line 44
it is not already in Unicode. Depending on local needs, this it is not already in Unicode. Depending on local needs, this
conversion may involve mapping some characters into other characters conversion may involve mapping some characters into other characters
as well as coding conversions. Those issues are discussed in as well as coding conversions. Those issues are discussed in
[IDNA2008-Mapping] and the mapping-related sections (Sections 4.4, 6, [IDNA2008-Mapping] and the mapping-related sections (Sections 4.4, 6,
and 7.3) of [IDNA2008-Rationale]. The result MUST be a Unicode and 7.3) of [IDNA2008-Rationale]. The result MUST be a Unicode
string in NFC form. string in NFC form.
5.3. A-label Input 5.3. A-label Input
If the input to this procedure appears to be an A-label (i.e., it If the input to this procedure appears to be an A-label (i.e., it
starts in "xn--"), the lookup application MAY attempt to convert it starts in "xn--", interpreted case-insensitively), the lookup
to a U-label, first ensuring that the A-label is entirely in lower application MAY attempt to convert it to a U-label, first ensuring
case, and apply the tests of Section 5.4 and the conversion of that the A-label is entirely in lower case (converting it to lower
Section 5.5 to that form. If the label is converted to Unicode case if necessary), and apply the tests of Section 5.4 and the
(i.e., to U-label form) using the Punycode decoding algorithm, then conversion of Section 5.5 to that form. If the label is converted to
the processing specified in those two sections MUST be performed, and Unicode (i.e., to U-label form) using the Punycode decoding
the label MUST be rejected if the resulting label is not identical to algorithm, then the processing specified in those two sections MUST
the original. See Section 8.1 of [IDNA2008-Rationale] for additional be performed, and the label MUST be rejected if the resulting label
discussion on this topic. is not identical to the original. See Section 8.1 of
[IDNA2008-Rationale] for additional discussion on this topic.
Conversion from the A-label and testing that the result is a U-label Conversion from the A-label and testing that the result is a U-label
SHOULD be performed if the domain name will later be presented to the SHOULD be performed if the domain name will later be presented to the
user in native character form (this requires that the lookup user in native character form (this requires that the lookup
application be IDNA-aware). If those steps are not performed, the application be IDNA-aware). If those steps are not performed, the
lookup process SHOULD at least test to determine that the string is lookup process SHOULD at least test to determine that the string is
actually an A-label, examining it for the invalid formats specified actually an A-label, examining it for the invalid formats specified
in the Punycode decoding specification. Applications that are not in the Punycode decoding specification. Applications that are not
IDNA-aware will obviously omit that testing; others MAY treat the IDNA-aware will obviously omit that testing; others MAY treat the
string as opaque to avoid the additional processing at the expense of string as opaque to avoid the additional processing at the expense of
skipping to change at page 13, line 46 skipping to change at page 14, line 8
5.5. Punycode Conversion 5.5. Punycode Conversion
The string that has now been validated for lookup is converted to ACE The string that has now been validated for lookup is converted to ACE
form by applying the Punycode algorithm to the string and then adding form by applying the Punycode algorithm to the string and then adding
the ACE prefix. the ACE prefix.
5.6. DNS Name Resolution 5.6. DNS Name Resolution
The A-label resulting from the conversion in Section 5.5 or supplied The A-label resulting from the conversion in Section 5.5 or supplied
directly (see Section 5.3) is looked up in the DNS, using normal DNS directly (see Section 5.3) is combined with other labels as needed to
resolver procedures. The lookup can obviously either succeed form a fully-qualified domain name which is then looked up in the
(returning information) or fail. DNS, using normal DNS resolver procedures. The lookup can obviously
either succeed (returning information) or fail.
6. Security Considerations 6. Security Considerations
Security Considerations for this version of IDNA are described in Security Considerations for this version of IDNA are described in
[IDNA2008-Defs], except for the special issues associated with right [IDNA2008-Defs], except for the special issues associated with right
to left scripts and characters. The latter are discussed in to left scripts and characters. The latter are discussed in
[IDNA2008-BIDI]. [IDNA2008-BIDI].
In order to avoid intentional or accidental attacks from labels that
might be confused with others, special problems in rendering, and so
on, the IDNA model requires that registries exercise care and
thoughtfulness about what labels they choose to permit. That issue
is discussed in Section 4.3 of this document which, in turn, points
to a somewhat more extensive discussion in [IDNA2008-Rationale].
7. IANA Considerations 7. IANA Considerations
IANA actions for this version of IDNA are specified in IANA actions for this version of IDNA are specified in
[IDNA2008-Tables] and discussed informally in [IDNA2008-Rationale]. [IDNA2008-Tables] and discussed informally in [IDNA2008-Rationale].
The components of IDNA described in this document do not require any The components of IDNA described in this document do not require any
IANA actions. IANA actions.
8. Contributors 8. Contributors
While the listed editor held the pen, the original versions of this While the listed editor held the pen, the original versions of this
skipping to change at page 14, line 49 skipping to change at page 15, line 20
communities, too many people to list here. Nor would it have been communities, too many people to list here. Nor would it have been
possible without RFC 3490 itself and the efforts of the Working Group possible without RFC 3490 itself and the efforts of the Working Group
that defined it. Those people whose contributions are acknowledged that defined it. Those people whose contributions are acknowledged
in RFC 3490, [RFC4690], and [IDNA2008-Rationale] were particularly in RFC 3490, [RFC4690], and [IDNA2008-Rationale] were particularly
important. important.
Specific textual changes were incorporated into this document after Specific textual changes were incorporated into this document after
suggestions from the other contributors, Stephane Bortzmeyer, Vint suggestions from the other contributors, Stephane Bortzmeyer, Vint
Cerf, Lisa Dusseault, Paul Hoffman, Kent Karlsson, James Mitchell, Cerf, Lisa Dusseault, Paul Hoffman, Kent Karlsson, James Mitchell,
Erik van der Poel, Marcos Sanz, Andrew Sullivan, Wil Tan, Ken Erik van der Poel, Marcos Sanz, Andrew Sullivan, Wil Tan, Ken
Whistler, Chris Wright, and other WG participants. Special thanks Whistler, Chris Wright, and other WG participants and reviewers
are due to Paul Hoffman for permission to extract material from his including Martin Duerst, James Mitchell, Subramanian Moonesamy, Peter
Internet-Draft to form the basis for Appendix A. Saint-Andre, Margaret Wasserman, and Dan Winship who caught specific
errors and recommended corrections. Special thanks are due to Paul
Hoffman for permission to extract material from his Internet-Draft to
form the basis for Appendix A.
10. References 10. References
10.1. Normative References 10.1. Normative References
[IDNA2008-BIDI] [IDNA2008-BIDI]
Alvestrand, H. and C. Karp, "An updated IDNA criterion for Alvestrand, H. and C. Karp, "An updated IDNA criterion for
right-to-left scripts", August 2009, <https:// right-to-left scripts", August 2009, <https://
datatracker.ietf.org/drafts/draft-ietf-idnabis-bidi/>. datatracker.ietf.org/drafts/draft-ietf-idnabis-bidi/>.
skipping to change at page 16, line 48 skipping to change at page 17, line 19
February 2009, <https://datatracker.ietf.org/drafts/ February 2009, <https://datatracker.ietf.org/drafts/
draft-ietf-idnabis-rationale>. draft-ietf-idnabis-rationale>.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997. RFC 2136, April 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997. Specification", RFC 2181, July 1997.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999. RFC 2671, August 1999.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", "Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003. RFC 3490, March 2003.
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
Profile for Internationalized Domain Names (IDN)", Profile for Internationalized Domain Names (IDN)",
RFC 3491, March 2003. RFC 3491, March 2003.
skipping to change at page 23, line 26 skipping to change at page 23, line 47
o Adjusted discussion of changes to Punycode to make more precise. o Adjusted discussion of changes to Punycode to make more precise.
o Inserted text to clarify version matching between IDNA and o Inserted text to clarify version matching between IDNA and
Unicode. Unicode.
o Made several small changes based on Martin Duerst's review. o Made several small changes based on Martin Duerst's review.
o Substituted in Section numbers in references to other IDNA2008 o Substituted in Section numbers in references to other IDNA2008
documents. documents.
B.17. Version -17
This is the version of the document produced to reflect comments on
IETF Last Call. For the convenience of those who made comments and
of the IESG in evaluating them, this section therefore identifies
non-editorial changes made in response to Last Call comments in
somewhat more detail than may be usual.
o Eliminated the use of "Fake A-label" in this document because it
was causing confusion. Instead, the material in Section 4.2.1
that used that terminology has been recast to be specific about
the restriction. (Margaret Wasserman, Ops Directorate review.)
o Additional paragraph added to Security Considerations to call out
the Registry Restrictions/ permitted name policy issue. (Margaret
Wasserman, Ops Directorate review.)
o The statement "IDNA applies only to DNS labels" changed to "IDNA
applies only to a specific subset of DNS labels" because it
doesn't apply to all of them. (Dan Winship review, 20091013)
o Clarified some "label" versus "domain name" terminology. (Dan
Winship review, 20091013)
o Corrected an error in reference to RFC 1034 to point to RFC 1035
instead. (Dan Winship review, 20091013)
o Corrected title and a reference in 4.2.4. (Dan Winship review,
20091013)
o Restructured the last paragraph of Section 4.4 to finish
reflecting the change removing the 63 octet limit on U-labels.
(Dan Winship review, 20091013)
o Another patch to the case-sensitivity of A-labels. (James
Mitchell, 20091014)
o Added text to 3.2 to explicitly indicate that IDNA-aware
applications may choose to accept A-labels, U-labels, or both.
(Peter Saint-Andre, 20091019)
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. 32 change blocks. 
57 lines changed or deleted 113 lines changed or added

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