draft-ietf-idnabis-protocol-12.txt   draft-ietf-idnabis-protocol-13.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: November 9, 2009 Expires: January 13, 2010
Internationalized Domain Names in Applications (IDNA): Protocol Internationalized Domain Names in Applications (IDNA): Protocol
draft-ietf-idnabis-protocol-12.txt draft-ietf-idnabis-protocol-13.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 November 9, 2009. This Internet-Draft will expire on January 13, 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 33 skipping to change at page 3, line 33
4.4. Punycode Conversion . . . . . . . . . . . . . . . . . . . 10 4.4. Punycode Conversion . . . . . . . . . . . . . . . . . . . 10
4.5. Insertion in the Zone . . . . . . . . . . . . . . . . . . 10 4.5. Insertion in the Zone . . . . . . . . . . . . . . . . . . 10
5. Domain Name Lookup Protocol . . . . . . . . . . . . . . . . . 10 5. Domain Name Lookup Protocol . . . . . . . . . . . . . . . . . 10
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. Character Changes in Preprocessing or the User 5.3. Character Changes in Preprocessing or the User
Interface . . . . . . . . . . . . . . . . . . . . . . . . 11 Interface . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4. A-label Input . . . . . . . . . . . . . . . . . . . . . . 12 5.4. A-label Input . . . . . . . . . . . . . . . . . . . . . . 12
5.5. Validation and Character List Testing . . . . . . . . . . 13 5.5. Validation and Character List Testing . . . . . . . . . . 13
5.6. Punycode Conversion . . . . . . . . . . . . . . . . . . . 14 5.6. Punycode Conversion . . . . . . . . . . . . . . . . . . . 14
5.7. DNS Name Resolution . . . . . . . . . . . . . . . . . . . 14 5.7. DNS Name Resolution . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Local Mapping Alternatives . . . . . . . . . . . . . 18 Appendix A. Local Mapping Alternatives . . . . . . . . . . . . . 18
A.1. Transitional Mapping Model . . . . . . . . . . . . . . . . 18 A.1. Transitional Mapping Model . . . . . . . . . . . . . . . . 19
A.1.1. Fallback Lookup . . . . . . . . . . . . . . . . . . . 19 A.1.1. Fallback Lookup . . . . . . . . . . . . . . . . . . . 19
A.1.2. Two-step Lookup . . . . . . . . . . . . . . . . . . . 19 A.1.2. Two-step Lookup . . . . . . . . . . . . . . . . . . . 20
A.2. Internationalized Resource Identifier (IRI) Mapping A.2. Internationalized Resource Identifier (IRI) Mapping
Model . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Model . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix B. Summary of Major Changes from IDNA2003 . . . . . . . 21 Appendix B. Summary of Major Changes from IDNA2003 . . . . . . . 21
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 21 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 22
C.1. Changes between Version -00 and -01 of C.1. Changes between Version -00 and -01 of
draft-ietf-idnabis-protocol . . . . . . . . . . . . . . . 21 draft-ietf-idnabis-protocol . . . . . . . . . . . . . . . 22
C.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 22 C.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 22
C.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 22 C.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 22
C.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 22 C.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 23
C.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 22 C.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 23
C.6. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 23 C.6. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 23
C.7. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 23 C.7. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 23
C.8. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 23 C.8. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 24
C.9. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 24 C.9. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 24
C.10. Version -10 . . . . . . . . . . . . . . . . . . . . . . . 24 C.10. Version -10 . . . . . . . . . . . . . . . . . . . . . . . 24
C.11. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 24 C.11. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 25
C.12. Version -12 . . . . . . . . . . . . . . . . . . . . . . . 25 C.12. Version -12 . . . . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 C.13. Version -13 . . . . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
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 B discusses the relationship between this specification and Appendix B discusses the relationship between this specification and
the earlier version of IDNA (referred to here as "IDNA2003") and the the earlier version of IDNA (referred to here as "IDNA2003") and the
rationale for these changes, along with considerable explanatory rationale for these changes, along with considerable explanatory
skipping to change at page 11, line 7 skipping to change at page 11, line 7
serious problems with the protocol, the lookup-side tests are more serious problems with the protocol, the lookup-side tests are more
permissive and rely on the assumption that names that are present in permissive and rely on the assumption that names that are present in
the DNS are valid. That assumption is, however, a weak one because the DNS are valid. That assumption is, however, a weak one because
the presence of wild cards in the DNS might cause a string that is the presence of wild cards in the DNS might cause a string that is
not actually registered in the DNS to be successfully looked up. not actually registered in the DNS to be successfully looked up.
The two steps in Section 5.2 and Section 5.3 are required. The two steps in Section 5.2 and Section 5.3 are required.
[[anchor14: Note in Draft: Try to reorganize and renumber Section 5 [[anchor14: Note in Draft: Try to reorganize and renumber Section 5
(Lookup) so that it exactly parallels Section 4 (Registration). This (Lookup) so that it exactly parallels Section 4 (Registration). This
has not been done in drafts -10 through -12 because the task will be has not been done in drafts -10 through -13 because the task will be
much easier if the local mapping material is pulled from here (and much easier if the local mapping material is pulled from here (and
there is no point trying to align the section numbers twice).]] 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
skipping to change at page 11, line 30 skipping to change at page 11, line 30
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. A Unicode string may require it is not already Unicode. A Unicode string may require
normalization as discussed in Section 4.1. The result MUST be a normalization as 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 -12. This entire section is likely to need [[anchor15: Note in Draft -13. This entire section is likely to need
to be rewritten when we make final decisions about mapping.]] significant revision when we make final decisions about mapping. The
changes from -12 are intended simply to illustrate one of the ways in
which the mapping material might be incorporated if we keep it... and
to fix a possible ambiguity about the NFC requirement for mapping
output.]]
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
are expected to be in either ASCII form (including A-labels) or to are expected to be in either ASCII form (including A-labels) or to
contain U-labels, rather than being in forms requiring mapping or contain U-labels, rather than being in forms requiring mapping or
other conversions. other conversions.
The mapping issue and some suggestions and tradeoffs are discussed in
[IDNA2008-Mapping]. Note that this specification does not require
that the processing into Unicode (See Section 5.2 above) be applied
as a separate step if it incorporated into some mapping process as
described in [IDNA2008-Mapping].
Other examples of processing for localization might be applied, Other examples of processing for localization might be applied,
especially to direct user input, at this point. They include especially to direct user input, at this point. They include
interpreting various characters as separating domain name components interpreting various characters as separating domain name components
from each other (label separators) because they either look like from each other (label separators) because they either look like
periods or are used to separate sentences, mapping halfwidth or periods or are used to separate sentences, mapping halfwidth or
fullwidth East Asian characters to the common form permitted in fullwidth East Asian characters to the common form permitted in
labels, or giving special treatment to characters whose presentation labels, or giving special treatment to characters whose presentation
forms are dependent only on placement in the label. Such forms are dependent only on placement in the label. Such
localization changes are also outside the scope of this localization changes are also outside the scope of this
specification. specification.
skipping to change at page 12, line 28 skipping to change at page 12, line 38
of preprocessing, especially to strings stored in files, poses a of preprocessing, especially to strings stored in files, poses a
threat to consistent and predictable behavior for the user even if threat to consistent and predictable behavior for the user even if
not to actual interoperability. not to actual interoperability.
Because these transformations are local, it is important that domain Because these transformations are local, it is important that domain
names that might be passed between systems (e.g., in IRIs) be names that might be passed between systems (e.g., in IRIs) be
U-labels or A-labels and not forms that might be accepted locally as U-labels or A-labels and not forms that might be accepted locally as
a consequence of this step. This step is not standardized as part of a consequence of this step. This step is not standardized as part of
IDNA, and is not further specified here. IDNA, and is not further specified here.
If this step is applied, the results still MUST be in NFC form as
above. The step must not denormalize the characters.
5.4. A-label Input 5.4. 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--"), the lookup application MAY attempt to convert it
to a U-label and apply the tests of Section 5.5 and the conversion of to a U-label and apply the tests of Section 5.5 and the conversion of
Section 5.6 to that form. If the label is converted to Unicode Section 5.6 to that form. If the label is converted to Unicode
(i.e., to U-label form) using the Punycode decoding algorithm, then (i.e., to U-label form) using the Punycode decoding algorithm, then
the processing specified in those two sections MUST be performed, and the processing specified in those two sections MUST be performed, and
the label MUST be rejected if the resulting label is not identical to the label MUST be rejected if the resulting label is not identical to
the original. See the Name Server Considerations section of the original. See the Name Server Considerations section of
skipping to change at page 13, line 11 skipping to change at page 13, line 22
testing; others MAY treat the string as opaque to avoid the testing; others MAY treat the string as opaque to avoid the
additional processing at the expense of providing less protection and additional processing at the expense of providing less protection and
information to users. information to users.
5.5. Validation and Character List Testing 5.5. Validation and Character List Testing
As with the registration procedure described in Section 4, the As with the registration procedure described in Section 4, the
Unicode string is checked to verify that all characters that appear Unicode string is checked to verify that all characters that appear
in it are valid as input to IDNA lookup processing. As discussed in it are valid as input to IDNA lookup processing. As discussed
above and in [IDNA2008-Rationale], the lookup check is more liberal above and in [IDNA2008-Rationale], the lookup check is more liberal
than the registration one. Putative labels with any of the following than the registration one. Labels that have not been fully evaluated
characteristics MUST BE rejected prior to DNS lookup: for conformance to the applicable rules are referred to as "putative"
labels as discussed in [IDNA2008-Defs][[anchor16: ??? Insert section
number -- 2.2.3 as of Defs-09]]. Putative labels with any of the
following characteristics MUST BE rejected prior to DNS lookup:
o Labels containing code points that are unassigned in the version o Labels containing code points that are unassigned in the version
of Unicode being used by the application, i.e.,in the UNASSIGNED of Unicode being used by the application, i.e.,in the UNASSIGNED
category of [IDNA2008-Tables]. category of [IDNA2008-Tables].
o Labels that are not in NFC form as defined in [Unicode-UAX15]. o Labels that are not in NFC form as defined in [Unicode-UAX15].
o Labels containing prohibited code points, i.e., those that are o Labels containing prohibited code points, i.e., those that are
assigned to the "DISALLOWED" category in the permitted character assigned to the "DISALLOWED" category in the permitted character
table [IDNA2008-Tables]. table [IDNA2008-Tables].
skipping to change at page 17, line 25 skipping to change at page 17, line 37
10.2. Informative References 10.2. Informative References
[ASCII] American National Standards Institute (formerly United [ASCII] American National Standards Institute (formerly United
States of America Standards Institute), "USA Code for States of America Standards Institute), "USA Code for
Information Interchange", ANSI X3.4-1968, 1968. Information Interchange", ANSI X3.4-1968, 1968.
ANSI X3.4-1968 has been replaced by newer versions with ANSI X3.4-1968 has been replaced by newer versions with
slight modifications, but the 1968 version remains slight modifications, but the 1968 version remains
definitive for the Internet. definitive for the Internet.
[IDNA2008-Mapping]
Resnick, P., "Mapping Characters in IDNA", July 2009, <htt
ps://datatracker.ietf.org/drafts/
draft-ietf-idnabis-mapping/>.
[IDNA2008-Rationale] [IDNA2008-Rationale]
Klensin, J., Ed., "Internationalizing Domain Names for Klensin, J., Ed., "Internationalizing Domain Names for
Applications (IDNA): Issues, Explanation, and Rationale", Applications (IDNA): Issues, Explanation, and Rationale",
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.
skipping to change at page 20, line 26 skipping to change at page 20, line 44
In particular, if both interpretations of the name return values, the In particular, if both interpretations of the name return values, the
lookup application has no practical way to tell whether the relevant lookup application has no practical way to tell whether the relevant
registry has applied "variant" or "bundling" techniques to ensure registry has applied "variant" or "bundling" techniques to ensure
that both domain names are under the same control or not. From that that both domain names are under the same control or not. From that
perspective, the approach in the previous subsection assumes that has perspective, the approach in the previous subsection assumes that has
been done (if the IDNA2003-interpretation label is present at all) been done (if the IDNA2003-interpretation label is present at all)
while this one assumes that such bundling is unlikely to have while this one assumes that such bundling is unlikely to have
occurred. occurred.
[[anchor25: Note in Draft: If this appendix is used, RFC3490 must be [[anchor26: Note in Draft: If this appendix is used, RFC3490 must be
moved from Informative to Normative.]] moved from Informative to Normative.]]
A.2. Internationalized Resource Identifier (IRI) Mapping Model A.2. Internationalized Resource Identifier (IRI) Mapping Model
This subsection is intended to be descriptive of an approach that This subsection is intended to be descriptive of an approach that
lies outside IDNA, rather than a normative component of it. If it lies outside IDNA, rather than a normative component of it. If it
were adopted, Section 5.3 would be deleted and the material below were adopted, Section 5.3 would be deleted and the material below
would be referenced, either as a non-normative Appendix in Protocol would be referenced, either as a non-normative Appendix in Protocol
or, more reasonably, as a section of Rationale. or, more reasonably, as a section of Rationale.
skipping to change at page 21, line 45 skipping to change at page 22, line 18
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 C. Change Log Appendix C. Change Log
[[anchor28: RFC Editor: Please remove this appendix.]] [[anchor29: RFC Editor: Please remove this appendix.]]
C.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.
C.2. Version -02 C.2. Version -02
skipping to change at page 25, line 28 skipping to change at page 25, line 45
appropriateness or placement of text. If there are no comments on appropriateness or placement of text. If there are no comments on
the mailing list, the editor will apply his own judgment. the mailing list, the editor will apply his own judgment.
o Several of the usual small typos and other editorial errors have o Several of the usual small typos and other editorial errors have
been corrected. been corrected.
o Section 5 has still not been reorganized to match Section 4 in o Section 5 has still not been reorganized to match Section 4 in
structure and subsection numbering -- will be done as soon as the structure and subsection numbering -- will be done as soon as the
mapping decisions and references are final. mapping decisions and references are final.
C.13. Version -13
o Modified the "putative label" text to better explain the term and
explicitly point back to Defs.
o Slight rewrite of Section 5.3 to clarify the NFC requirement and
to start the transition toward having some of the explanation in
the Mapping document. The latter might need to be undone as WG
consensus evolves.
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. 21 change blocks. 
21 lines changed or deleted 53 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/