draft-ietf-idnabis-protocol-09.txt   draft-ietf-idnabis-protocol-10.txt 
Network Working Group J. Klensin Network Working Group J. Klensin
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: August 24, 2009 Expires: September 6, 2009
Internationalized Domain Names in Applications (IDNA): Protocol Internationalized Domain Names in Applications (IDNA): Protocol
draft-ietf-idnabis-protocol-09.txt draft-ietf-idnabis-protocol-10.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. provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 24, 2009. This Internet-Draft will expire on September 6, 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 Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Abstract Abstract
This document supplies the protocol definition for a revised and This document supplies the protocol definition for a revised and
updated specification for internationalized domain names (IDNs). The updated specification for internationalized domain names (IDNs). The
rationale for these changes, the relationship to the older rationale for these changes, the relationship to the older
specification, and important terminology are provided in other specification, and important terminology are provided in other
documents. This document specifies the protocol mechanism, called documents. This document specifies the protocol mechanism, called
Internationalizing Domain Names in Applications (IDNA), for Internationalizing Domain Names in Applications (IDNA), for
registering and looking up IDNs in a way that does not require registering and looking up IDNs in a way that does not require
skipping to change at page 3, line 19 skipping to change at page 3, line 19
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements and Applicability . . . . . . . . . . . . . . . . 6 3. Requirements and Applicability . . . . . . . . . . . . . . . . 6
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 Process . . . . . . . . . . . . 8 4.1. Input to IDNA Registration Process . . . . . . . . . . . . 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 . . . . 8 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 . . . . . . . . . . . 10 4.2.4. Registration Validation Summary . . . . . . . . . . . 10
4.3. Registry Restrictions . . . . . . . . . . . . . . . . . . 10 4.3. Registry Restrictions . . . . . . . . . . . . . . . . . . 10
4.4. Punycode Conversion . . . . . . . . . . . . . . . . . . . 11 4.4. Punycode Conversion . . . . . . . . . . . . . . . . . . . 11
4.5. Insertion in the Zone . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . 12
5.2. Conversion to Unicode . . . . . . . . . . . . . . . . . . 11 5.2. Conversion to Unicode . . . . . . . . . . . . . . . . . . 12
5.3. Character Changes in Preprocessing or the User 5.3. Character Changes in Preprocessing or the User
Interface . . . . . . . . . . . . . . . . . . . . . . . . 12 Interface . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4. A-label Input . . . . . . . . . . . . . . . . . . . . . . 13 5.4. A-label Input . . . . . . . . . . . . . . . . . . . . . . 13
5.5. Validation and Character List Testing . . . . . . . . . . 13 5.5. Validation and Character List Testing . . . . . . . . . . 14
5.6. Punycode Conversion . . . . . . . . . . . . . . . . . . . 14 5.6. Punycode Conversion . . . . . . . . . . . . . . . . . . . 15
5.7. DNS Name Resolution . . . . . . . . . . . . . . . . . . . 14 5.7. DNS Name Resolution . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Summary of Major Changes from IDNA2003 . . . . . . . 18 Appendix A. Local Mapping Alternatives . . . . . . . . . . . . . 19
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 19 A.1. Transitional Mapping Model . . . . . . . . . . . . . . . . 19
B.1. Changes between Version -00 and -01 of A.2. Internationalized Resource Identifier (IRI) Mapping
draft-ietf-idnabis-protocol . . . . . . . . . . . . . . . 19 Model . . . . . . . . . . . . . . . . . . . . . . . . . . 20
B.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 19 Appendix B. Summary of Major Changes from IDNA2003 . . . . . . . 21
B.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 19 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 22
B.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 20 C.1. Changes between Version -00 and -01 of
B.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 20 draft-ietf-idnabis-protocol . . . . . . . . . . . . . . . 22
B.6. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 20 C.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 22
B.7. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 20 C.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 22
B.8. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 21 C.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 22
B.9. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 21 C.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 C.6. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 23
C.7. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 23
C.8. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 23
C.9. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 24
C.10. Version -10 . . . . . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
This document supplies the protocol definition for a revised and This document supplies the protocol definition for a revised and
updated specification for internationalized domain names. Essential updated specification for internationalized domain names. Essential
definitions and terminology for understanding this document and a definitions and terminology for understanding this document and a
road map of the collection of documents that make up IDNA2008 appear road map of the collection of documents that make up IDNA2008 appear
in [IDNA2008-Defs]. Appendix A discusses the relationship between in [IDNA2008-Defs]. Appendix B discusses the relationship between
this specification and the earlier version of IDNA (referred to here this specification and the earlier version of IDNA (referred to here
as "IDNA2003") and the rationale for these changes, along with as "IDNA2003") and the rationale for these changes, along with
considerable explanatory material and advice to zone administrators considerable explanatory material and advice to zone administrators
who support IDNs is provided in another documents, notably who support IDNs is provided in another documents, notably
[IDNA2008-Rationale]. [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 depend on changes to any infrastructure. In IDNA does not depend on changes to any infrastructure. In
skipping to change at page 8, line 12 skipping to change at page 8, line 12
procedure is implementation independent; any sequence of steps that procedure is implementation independent; any sequence of steps that
produces exactly the same result for all labels is considered a valid produces exactly the same result for all labels is considered a valid
implementation. implementation.
Note that, while the registration and lookup protocols (Section 5) Note that, while the registration and lookup protocols (Section 5)
are very similar in most respects, they are different and are very similar in most respects, they are different and
implementers should carefully follow the steps they are implementing. implementers should carefully follow the steps they are implementing.
4.1. Input to IDNA Registration Process 4.1. Input to IDNA Registration Process
[[anchor8: Note in Draft: This subsection is new in -08, based on [[anchor8: Note in Draft: This subsection is new in -09/, based on
comments on the mailing list in January and February 2009. It comments on the mailing list in January and February 2009. It
replaces the previous first two subsections of this section and replaces the previous first two subsections of this section and
completely eliminates the discussion of local mapping for completely eliminates the discussion of local mapping for
registration.]] registration.]]
Registration processes are outside the scope of these protocols and Registration processes are outside the scope of these protocols and
may differ significantly depending on local needs. By the time a may differ significantly depending on local needs. By the time a
string enters the IDNA registration process as described in this string enters the IDNA registration process as described in this
specification, it is expected to be in Unicode and MUST be in Unicode specification, it is expected to be in Unicode and MUST be in Unicode
Normalization Form C (NFC [Unicode-UAX15]). Entities responsible for Normalization Form C (NFC [Unicode-UAX15]). Entities responsible for
zone files ("registries") are expected to accept only the exact zone files ("registries") are expected to accept only the exact
string for which registration is requested, free of any mappings or string for which registration is requested, free of any mappings or
local adjustments. They SHOULD avoid any possible ambiguity by local adjustments. They SHOULD avoid any possible ambiguity by
accepting registrations only for A-labels, possibly paired with the accepting registrations only for A-labels, possibly paired with the
relevant U-labels so that they can verify the correspondence. relevant U-labels so that they can verify the correspondence.
4.2. Permitted Character and Label Validation 4.2. Permitted Character and Label Validation
4.2.1. Input Format 4.2.1. Input Format
The registry MAY permit submission of labels in A-label form. If it The registry MAY permit submission of labels in A-label form and is
does so, it MUST perform a conversion to a U-label, perform the steps encouraged to accept both the A-label form and the U-label one. If
and tests described below, and verify that the A-label produced by it does so, it MUST perform a conversion to a U-label, perform the
the step in Section 4.4 matches the one provided as input. If, for steps and tests described below, and verify that the A-label produced
some reason, it does not, the registration MUST be rejected. If the by the step in Section 4.4 matches the one provided as input. In
conversion to a U-label is not performed, the registry MUST verify addition, if a U-label was provided, that U-label and the one
that the A-label is superficially valid, i.e., that it does not obtained by conversion of the A-label MUST match exactly. If, for
violate any of the rules of Punycode [RFC3492] encoding such as the some reason, these tests fail, the registration MUST be rejected. If
prohibition on trailing hyphen-minus, appearance of non-basic the conversion to a U-label is not performed, the registry MUST still
characters before the delimiter, and so on. Invalid strings that verify that the A-label is superficially valid, i.e., that it does
appear to be A-labels MUST NOT be placed in DNS zones. not violate any of the rules of Punycode [RFC3492] encoding such as
the prohibition on trailing hyphen-minus, appearance of non-basic
characters before the delimiter, and so on. Fake A-labels, i.e.,
invalid strings that appear to be A-labels but are not, 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 is checked to verify that characters The candidate Unicode string is checked to verify that characters
that IDNA does not permit do not appear in it. Those characters are that IDNA does not permit do not appear in it. Those characters are
identified in the "DISALLOWED" and "UNASSIGNED" lists that are identified in the "DISALLOWED" and "UNASSIGNED" lists that are
specified in [IDNA2008-Tables] and described informally in specified in [IDNA2008-Tables] and described informally in
[IDNA2008-Rationale]. Characters that are either DISALLOWED or [IDNA2008-Rationale]. Characters that are either DISALLOWED or
UNASSIGNED MUST NOT be part of labels to be processed for UNASSIGNED MUST NOT be part of labels to be processed for
registration in the DNS. registration in the DNS.
skipping to change at page 10, line 14 skipping to change at page 10, line 19
4.2.3.4. Labels Containing Characters Written Right to Left 4.2.3.4. Labels Containing Characters Written Right to Left
Special tests are required for strings containing characters that are Special tests are required for strings containing characters that are
normally written from right to left. The criteria for classifying normally written from right to left. The criteria for classifying
characters in terms of directionality are identified in the "Bidi" characters in terms of directionality are identified in the "Bidi"
document [IDNA2008-BIDI] in this series. That document also document [IDNA2008-BIDI] in this series. That document also
describes conditions for strings that contain one or more of those describes conditions for strings that contain one or more of those
characters to be U-labels. The tests for those conditions, specified characters to be U-labels. The tests for those conditions, specified
there, are applied. Strings that contain right to left characters there, are applied. Strings that contain right to left characters
that do not conform to the IDNA Bidi rules MUST NOT be inserted as but that do not conform to the IDNA Bidi rules MUST NOT be inserted
labels in zone files. as labels in zone files.
4.2.4. Registration Validation Summary 4.2.4. Registration Validation Summary
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 the above tests, and produced by the steps above, whose contents pass all of the tests in
are 63 or fewer characters long in ACE form (see Section 4.4), are Section 4.2, and are 63 or fewer characters long in ACE form (see
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, and for labels that are invalid invalid combinations of characters, for labels that are invalid even
even if the characters they contain are valid individually. if the characters they contain are valid individually, and for labels
that do not conform to the restrictions for strings containing right
to left characters.
4.3. Registry Restrictions 4.3. Registry Restrictions
Registries at all levels of the DNS, not just the top level, are Registries at all levels of the DNS, not just the top level, are
expected to establish policies about the labels that may be expected to establish policies about the labels that may be
registered, and for the processes associated with that action. While registered, and for the processes associated with that action. While
exact policies are not specified as part of IDNA2008 and it is exact policies are not specified as part of IDNA2008 and it is
expected that different registries may specify different policies, expected that different registries may specify different policies,
there SHOULD be policies. Even a trivial policy (e.g., "anything can there SHOULD be policies. Even a trivial policy (e.g., "anything can
be registered in this zone that can be represented as an A-label - be registered in this zone that can be represented as an A-label -
skipping to change at page 11, line 36 skipping to change at page 11, line 42
Lookup is conceptually different from registration and different Lookup is conceptually different from registration and different
tests are applied on the client. Although some validity checks are tests are applied on the client. Although some validity checks are
necessary to avoid serious problems with the protocol (see necessary to avoid serious problems with the protocol (see
Section 5.5ff.), the lookup-side tests are more permissive and rely Section 5.5ff.), the lookup-side tests are more permissive and rely
on the assumption that names that are present in the DNS are valid. on the assumption that names that are present in the DNS are valid.
That assumption is, however, a weak one because the presence of wild That assumption is, however, a weak one because the presence of wild
cards in the DNS might cause a string that is not actually registered cards in the DNS might cause a string that is not actually registered
in the DNS to be successfully looked up. in the DNS to be successfully looked up.
For convenience in description, we introduce an extra concept, a
"C-label", to describe a string that has the same appearance as an
A-label but that has been verified only to meet the somewhat more
flexible lookup requirements.
[[anchor14: Note in Draft: Try to reorganize and renumber Section 5
(Lookup) so that it exactly parallels Section 4 (Registration). This
has no been done in draft -10 because the task will be much easier if
the local mapping material is pulled from here (and there is no point
trying to align the section numbers twice).]]
5.1. Label String Input 5.1. Label String Input
The user supplies a string in the local character set, typically by The user supplies a string in the local character set, typically by
typing it or clicking on, or copying and pasting, a resource typing it or clicking on, or copying and pasting, a resource
identifier, e.g., a URI [RFC3986] or IRI [RFC3987] from which the identifier, e.g., a URI [RFC3986] or IRI [RFC3987] from which the
domain name is extracted. Alternately, some process not directly domain name is extracted. Alternately, some process not directly
involving the user may read the string from a file or obtain it in involving the user may read the string from a file or obtain it in
some other way. Processing in this step and the next two are local some other way. Processing in this step and the next two are local
matters, to be accomplished prior to actual invocation of IDNA, but matters, to be accomplished prior to actual invocation of IDNA, but
at least the two steps in Section 5.2 and Section 5.3 must be at least the two steps in Section 5.2 and Section 5.3 must be
skipping to change at page 12, line 10 skipping to change at page 12, line 28
5.2. Conversion to Unicode 5.2. Conversion to Unicode
The string is converted from the local character set into Unicode, if The string is converted from the local character set into Unicode, if
it is not already Unicode. The exact nature of this conversion is it is not already Unicode. The exact nature of this conversion is
beyond the scope of this document, but may involve normalization beyond the scope of this document, but may involve normalization
identical to that discussed in Section 4.1. The result MUST be a identical to that discussed in Section 4.1. The result MUST be a
Unicode string in NFC form. Unicode string in NFC form.
5.3. Character Changes in Preprocessing or the User Interface 5.3. Character Changes in Preprocessing or the User Interface
[[anchor15: Note in Draft -10. As of the time this draft was posted,
the WG was continuing to discuss various alternatives to this
section, which was pragmatic relative to various options and behavior
but that seems to make no one happy from a predictability or
transition standpoint. Please see the (temporary) first appendix to
this document for a first cut at possible alternate formulations.]]
The Unicode string MAY then be processed to prevent confounding of The Unicode string MAY then be processed to prevent confounding of
user expectations. For instance, it might be reasonable, at this user expectations. For instance, it might be reasonable, at this
step, to convert all upper case characters to lower case, if this step, to convert all upper case characters to lower case, if this
makes sense in the user's environment, but even this should be makes sense in the user's environment, but even this should be
approached with caution due to some edge cases: in the long term, it approached with caution due to some edge cases: in the long term, it
is probably better for users to understand IDNs strictly in lower- is probably better for users to understand IDNs strictly in lower-
case, U-label, form. More generally, preprocessing may be useful to case, U-label, form. More generally, preprocessing may be useful to
smooth the transition from IDNA2003, especially for direct user smooth the transition from IDNA2003, especially for direct user
input, but with similar cautions. In general, IDNs appearing in input, but with similar cautions. In general, IDNs appearing in
files and those transmitted across the network as part of protocols files and those transmitted across the network as part of protocols
skipping to change at page 14, line 45 skipping to change at page 15, line 22
presence or absence of labels in the DNS to determine the validity of presence or absence of labels in the DNS to determine the validity of
those labels and the validity of the characters they contain. If those labels and the validity of the characters they contain. If
they are registered, they are presumed to be valid; if they are not, they are registered, they are presumed to be valid; if they are not,
their possible validity is not relevant. A lookup application that their possible validity is not relevant. A lookup application that
declines to process a string that conforms to the rules above and declines to process a string that conforms to the rules above and
does not look it up in the DNS is not in conformance with this does not look it up in the DNS is not in conformance with this
protocol. protocol.
5.6. Punycode Conversion 5.6. Punycode Conversion
The validated string, a U-label, is converted to an A-label using the The validated string, an apparent U-label, is converted to an
Punycode algorithm with the ACE prefix added. apparent A-label using the Punycode algorithm with the ACE prefix
added. These label forms are "apparent" U-labels and A-labels
because not all of the tests used in the Registration procedure
(Section 4) to effectively define those terms precisely are applied
in this lookup procedure.
[[anchor16: Note in Draft: As of -10, we are back to "apparent" (or
"putative" if the WG prefers) label forms. The previous text
asserted that these strings were A-labels and U-labels, which was
clearly wrong, since those terms are defined in terms of complete
validity and all of the registration tests. Mark suggested an
alternative, which was to introduce a new term, C-label, which was a
superset of A-labels but with fewer test conditions. I like the
idea, but could not figure out how to make it work without also
introducing a near-U-label term, and that started to become much too
terminology heavy to be followed easily. Suggestions of ways out of
this, preferably with specific text for this document and Defs, would
be welcome.]]
5.7. DNS Name Resolution 5.7. DNS Name Resolution
The A-label is looked up in the DNS, using normal DNS resolver The resulting string (the apparent A-label) is looked up in the DNS,
procedures. using normal DNS resolver procedures.
6. Security Considerations 6. Security Considerations
Security Considerations for this version of IDNA except for the Security Considerations for this version of IDNA, except for the
special issues associated with right to left scripts and characters special issues associated with right to left scripts and characters,
are described in [IDNA2008-Defs]. Specific issues for labels are described in [IDNA2008-Defs]. Specific issues for labels
containing characters associated with scripts written right to left containing characters associated with scripts written right to left
appear in [IDNA2008-BIDI]. appear in [IDNA2008-BIDI].
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.
skipping to change at page 16, line 5 skipping to change at page 16, line 45
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, Mark Davis, Paul Hoffman, Kent Karlsson, Erik van der Poel, Cerf, Mark Davis, Paul Hoffman, Kent Karlsson, Erik van der Poel,
Marcos Sanz, Andrew Sullivan, Ken Whistler, and other WG Marcos Sanz, Andrew Sullivan, Ken Whistler, and other WG
participants. Special thanks are due to Paul Hoffman for permission participants. Special thanks are due to Paul Hoffman for permission
to extract material from his Internet-Draft to form the basis for to extract material from his Internet-Draft to form the basis for
Appendix A Appendix B
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", July 2008, <https:// right-to-left scripts", July 2008, <https://
datatracker.ietf.org/drafts/draft-ietf-idnabis-bidi/>. datatracker.ietf.org/drafts/draft-ietf-idnabis-bidi/>.
skipping to change at page 18, line 28 skipping to change at page 19, line 22
(IDNs)", RFC 4690, September 2006. (IDNs)", RFC 4690, September 2006.
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for
Internationalized Email", RFC 4952, July 2007. Internationalized Email", RFC 4952, July 2007.
[Unicode] The Unicode Consortium, "The Unicode Standard, Version [Unicode] The Unicode Consortium, "The Unicode Standard, Version
5.0", 2007. 5.0", 2007.
Boston, MA, USA: Addison-Wesley. ISBN 0-321-48091-0 Boston, MA, USA: Addison-Wesley. ISBN 0-321-48091-0
Appendix A. Summary of Major Changes from IDNA2003 Appendix A. Local Mapping Alternatives
The subsections of this appendix are temporary and represent
different sketches of possible replacements for Section 5.3. They do
not represent an assertion of WG consensus or any assertion about the
possibility of including one of them as part of the WG's work
program. Instead, they are supplied only for purposes of comparison,
discussion, and, should it be relevant, refinement.
The first paragraph of each subsection describes how the material
would be placed relative to the existing main document text.
Subsequent paragraphs are the actual suggestions, although in
incomplete sketch form.
A.1. Transitional Mapping Model
If this subsection were adopted, Section 5.3 would be deleted and
this one would be inserted after, or integrated with, Section 5.7.
This specification does not support the extensive mappings from one
character to another, including Unicode Case Folding and
Compatibility Character mapping, of IDNA2003. It also changes the
interpretations of a small number of characters relative to IDNA2003.
Most applications, especially those with which IDNs have been used
for some time, will need to maintain reasonable compatibility with
files created under IDNA2003 and user interfaces designed for it.
This section specifies additional steps to be taken to provide
maximum IDNA2003 compatibility.
If an application requires IDNA2003 backward compatibility, it MUST
execute one of the two bulleted steps below.
o If the resolution attempt in Section 5.7 fails, the apparent
U-label is processed through the ToASCII operation specified in
IDNA2003 [RFC3490] and, if the two apparent A-labels are not
identical, the result is looked up. If it is found, the relevant
values are handled as if the resolution attempt in Section 5.7 had
succeeded with that value. If the resolution attempt in
Section 5.7 is successful, this step simply produces that value.
o Once the resolution attempt in Section 5.7 is completed, the
apparent U-label is processed through the ToASCII operation
specified in IDNA2003 [RFC3490]. The two apparent A-labels are
compared to each other. If they are not identical, the second one
is looked up as well. If one of the two lookups is successful and
the other is not, that value is used as the result of the lookup.
If both are successful, the user is presented with a choice. If
neither is successful, the IDNA lookup fails.
Note that, if both interpretations of the name return values, the
lookup application has no practical way to tell whether the relevant
registry has applied "variant" or "bundling" techniques to ensure
that both domain name are under the same control or not. From that
perspective, the first of these approaches assumes that has been done
(if the IDNA2003-interpretation label is present at all) while the
second assumes that such bundling is unlikely to have occurred.
[[anchor24: Note in Draft: If this appendix is used, RFC3490 must be
moved from Informative to Normative.]]
A.2. Internationalized Resource Identifier (IRI) Mapping Model
This subsection is intended to be descriptive of an approach that
lies outside IDNA, rather than a normative component of it. If it
were adopted, Section 5.3 would be deleted and the material below
would be referenced, either as a non-normative Appendix in Protocol
or, more reasonably, as a section of Rationale.
IDNA2003 supported extensive mappings from one character to another,
including Unicode Case Folding and Compatibility Character mapping.
Those mappings are no longer supported on registration and are
inconsistent with the "exact match" lookups that people expect from
the DNS. Some mapping should still be supported, both for
compatibility with applications that assume IDNA2003 and to avoid
confounding user expectations. The specific mappings involved are
not part of IDNA, but are expected to be specified as part of a
revision to the IRI specification [RFC3987] and the conversion from
IRI form to URI form. That change leaves mapping unspecified and
prohibited for actual domain names, however, in practice, most domain
names, especially in the web applications that appear to have been
most important for IDNs between the publication of IDNA2003 and the
release of this specification, are not interpreted as themselves but
as abbreviated form of URIs or IRIs and hence subject to the
transformation rules of the latter.
Appendix B. Summary of Major Changes from IDNA2003
1. Update base character set from Unicode 3.2 to Unicode version- 1. Update base character set from Unicode 3.2 to Unicode version-
agnostic. agnostic.
2. Separate the definitions for the "registration" and "lookup" 2. Separate the definitions for the "registration" and "lookup"
activities. activities.
3. Disallow symbol and punctuation characters except where special 3. Disallow symbol and punctuation characters except where special
exceptions are necessary. exceptions are necessary.
skipping to change at page 19, line 19 skipping to change at page 22, line 5
not just labels standing on their own) display in a less not just labels standing on their own) display in a less
surprising fashion whether they appear in obvious domain name surprising fashion whether they appear in obvious domain name
contexts or as part of running text in paragraphs. contexts or as part of running text in paragraphs.
9. Remove the dot separator from the mandatory part of the 9. Remove the dot separator from the mandatory part of the
protocol. protocol.
10. Make some currently-valid labels that are not actually IDNA 10. Make some currently-valid labels that are not actually IDNA
labels invalid. labels invalid.
Appendix B. Change Log Appendix C. Change Log
[[anchor20: RFC Editor: Please remove this appendix.]] [[anchor27: RFC Editor: Please remove this appendix.]]
B.1. Changes between Version -00 and -01 of draft-ietf-idnabis-protocol C.1. Changes between Version -00 and -01 of draft-ietf-idnabis-protocol
o Corrected discussion of SRV records. o Corrected discussion of SRV records.
o Several small corrections for clarity. o Several small corrections for clarity.
o Inserted more "open issue" placeholders. o Inserted more "open issue" placeholders.
B.2. Version -02 C.2. Version -02
o Rewrote the "conversion to Unicode" text in Section 5.2 as o Rewrote the "conversion to Unicode" text in Section 5.2 as
requested on-list. requested on-list.
o Added a comment (and reference) about EDNS0 to the "DNS Server o Added a comment (and reference) about EDNS0 to the "DNS Server
Conventions" section, which was also retitled. Conventions" section, which was also retitled.
o Made several editorial corrections and improvements in response to o Made several editorial corrections and improvements in response to
various comments. various comments.
o Added several new discussion placeholder anchors and updated some o Added several new discussion placeholder anchors and updated some
older ones. older ones.
B.3. Version -03 C.3. Version -03
o Trimmed change log, removing information about pre-WG drafts. o Trimmed change log, removing information about pre-WG drafts.
o Incorporated a number of changes suggested by Marcos Sanz in his o Incorporated a number of changes suggested by Marcos Sanz in his
note of 2008.07.17 and added several more placeholder anchors. note of 2008.07.17 and added several more placeholder anchors.
o Several minor editorial corrections and improvements. o Several minor editorial corrections and improvements.
o "Editor" designation temporarily removed because the automatic o "Editor" designation temporarily removed because the automatic
posting machinery does not accept it. posting machinery does not accept it.
B.4. Version -04 C.4. Version -04
o Removed Contextual Rule appendices for transfer to Tables. o Removed Contextual Rule appendices for transfer to Tables.
o Several changes, including removal of discussion anchors, based on o Several changes, including removal of discussion anchors, based on
discussions at IETF 72 (Dublin) discussions at IETF 72 (Dublin)
o Rewrote the preprocessing material (Section 5.3) somewhat. o Rewrote the preprocessing material (Section 5.3) somewhat.
B.5. Version -05 C.5. Version -05
o Updated part of the A-label input explanation (Section 5.4) per o Updated part of the A-label input explanation (Section 5.4) per
note from Erik van der Poel. note from Erik van der Poel.
B.6. Version -06 C.6. Version -06
o Corrected a few typographical errors. o Corrected a few typographical errors.
o Incorporated the material (formerly in Rationale) on the o Incorporated the material (formerly in Rationale) on the
relationship between IDNA2003 and IDNA2008 as an appendix and relationship between IDNA2003 and IDNA2008 as an appendix and
pointed to the new definitions document. pointed to the new definitions document.
o Text modified in several places to recognize the dangers of o Text modified in several places to recognize the dangers of
interaction between DNS wildcards and IDNs. interaction between DNS wildcards and IDNs.
o Text added to be explicit about the handling of edge and failure o Text added to be explicit about the handling of edge and failure
cases in Punycode encoding and decoding. cases in Punycode encoding and decoding.
o Revised for consistency with the new Definitions document and to o Revised for consistency with the new Definitions document and to
make the text read more smoothly. make the text read more smoothly.
B.7. Version -07 C.7. Version -07
o Multiple small textual and editorial changes and clarifications. o Multiple small textual and editorial changes and clarifications.
o Requirement for normalization clarified to apply to all cases and o Requirement for normalization clarified to apply to all cases and
conditions for preprocessing further clarified. conditions for preprocessing further clarified.
o Substantive change to Section 4.2.1, turning a SHOULD to a MUST o Substantive change to Section 4.2.1, turning a SHOULD to a MUST
(see note from Mark Davis, 19 November, 2008 18:14 -0800). (see note from Mark Davis, 19 November, 2008 18:14 -0800).
B.8. Version -08 C.8. Version -08
o Added some references and altered text to improve clarity. o Added some references and altered text to improve clarity.
o Changed the description of CONTEXTJ/CONTEXTO to conform to that in o Changed the description of CONTEXTJ/CONTEXTO to conform to that in
Tables. In other words, these are now treated as distinction Tables. In other words, these are now treated as distinction
categories (again), rather than as specially-flagged subsets of categories (again), rather than as specially-flagged subsets of
PROTOCOL VALID. PROTOCOL VALID.
o The discussion of label comparisons has been rewritten to make it o The discussion of label comparisons has been rewritten to make it
more precise and to clarify that one does not need to verify that more precise and to clarify that one does not need to verify that
a string is a [valid] A-label or U-label in order to test it for a string is a [valid] A-label or U-label in order to test it for
equality with another string. The WG should verify that the equality with another string. The WG should verify that the
current text is what is desired. current text is what is desired.
o Other changes to reflect post-IETF discussions or editorial o Other changes to reflect post-IETF discussions or editorial
improvements. improvements.
B.9. Version -09 C.9. Version -09
o Removed Security Considerations material to Defs document. o Removed Security Considerations material to Defs document.
o Removed the Name Server Considerations material to Rationale. o Removed the Name Server Considerations material to Rationale.
That material is not normative and not needed to implement the That material is not normative and not needed to implement the
protocol itself. protocol itself.
o Adjusted terminology to match new version of Defs. o Adjusted terminology to match new version of Defs.
o Removed all discussion of local mapping and option for it from o Removed all discussion of local mapping and option for it from
registration protocol. registration protocol.
o Removed some old placeholders and inquiries because no comments o Removed some old placeholders and inquiries because no comments
have been received. have been received.
o Small editorial corrections. o Small editorial corrections.
C.10. Version -10
o Rewrote the registration input material slightly to further
clarify the "no mapping on registration" principle.
o Added placeholder notes about several tasks, notably reorganizing
Section 4 and Section 5 so that subsection numbers are parallel.
o Cleaned up an incorrect use of the terms "A-label" and "U-label"
in the lookup phase that was spotted by Mark Davis. Inserted a
note there about alternate ways to deal with the resulting
terminology problem.
o Added a temporarily appendix (above) to document alternate
strategies for possible replacements for Section 5.3.
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. 34 change blocks. 
85 lines changed or deleted 227 lines changed or added

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