draft-ietf-idnabis-protocol-06.txt   draft-ietf-idnabis-protocol-07.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: May 6, 2009 Expires: June 1, 2009
Internationalized Domain Names in Applications (IDNA): Protocol Internationalized Domain Names in Applications (IDNA): Protocol
draft-ietf-idnabis-protocol-06.txt draft-ietf-idnabis-protocol-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 May 6, 2009. This Internet-Draft will expire on June 1, 2009.
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
changes to the DNS itself. IDNA is only meant for processing domain changes to the DNS itself. IDNA is only meant for processing domain
names, not free text. names, not free text.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Discussion Forum . . . . . . . . . . . . . . . . . . . . . 4 1.1. Discussion Forum . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements and Applicability . . . . . . . . . . . . . . . . 5 3. Requirements and Applicability . . . . . . . . . . . . . . . . 5
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. DNS Resource Records . . . . . . . . . . . . . . . . . 6 3.2.1. DNS Resource Records . . . . . . . . . . . . . . . . . 6
3.2.2. Non-domain-name Data Types Stored in the DNS . . . . . 6 3.2.2. Non-domain-name Data Types Stored in the DNS . . . . . 6
4. Registration Protocol . . . . . . . . . . . . . . . . . . . . 6 4. Registration Protocol . . . . . . . . . . . . . . . . . . . . 6
4.1. Proposed label . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Proposed label . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Conversion to Unicode and Normalization . . . . . . . . . 7 4.2. Conversion to Unicode and Normalization . . . . . . . . . 7
4.3. Permitted Character and Label Validation . . . . . . . . . 8 4.3. Permitted Character and Label Validation . . . . . . . . . 7
4.3.1. Rejection of Characters that are not Permitted . . . . 8 4.3.1. Input Format . . . . . . . . . . . . . . . . . . . . . 7
4.3.2. Label Validation . . . . . . . . . . . . . . . . . . . 8 4.3.2. Rejection of Characters that are not Permitted . . . . 8
4.3.3. Registration Validation Summary . . . . . . . . . . . 9 4.3.3. Label Validation . . . . . . . . . . . . . . . . . . . 8
4.3.4. Registration Validation Summary . . . . . . . . . . . 9
4.4. Registry Restrictions . . . . . . . . . . . . . . . . . . 9 4.4. Registry Restrictions . . . . . . . . . . . . . . . . . . 9
4.5. Punycode Conversion . . . . . . . . . . . . . . . . . . . 10 4.5. Punycode Conversion . . . . . . . . . . . . . . . . . . . 10
4.6. Insertion in the Zone . . . . . . . . . . . . . . . . . . 10 4.6. Insertion in the Zone . . . . . . . . . . . . . . . . . . 10
5. Domain Name Lookup Protocol . . . . . . . . . . . . . . . . . 10 5. Domain Name Lookup Protocol . . . . . . . . . . . . . . . . . 10
5.1. Label String Input . . . . . . . . . . . . . . . . . . . . 10 5.1. Label String Input . . . . . . . . . . . . . . . . . . . . 10
5.2. Conversion to Unicode . . . . . . . . . . . . . . . . . . 10 5.2. Conversion to Unicode . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . 12 5.5. Validation and Character List Testing . . . . . . . . . . 12
5.6. Punycode Conversion . . . . . . . . . . . . . . . . . . . 13 5.6. Punycode Conversion . . . . . . . . . . . . . . . . . . . 13
5.7. DNS Name Resolution . . . . . . . . . . . . . . . . . . . 13 5.7. DNS Name Resolution . . . . . . . . . . . . . . . . . . . 13
6. Name Server Considerations . . . . . . . . . . . . . . . . . . 13 6. Name Server Considerations . . . . . . . . . . . . . . . . . . 14
6.1. Processing Non-ASCII Strings . . . . . . . . . . . . . . . 14 6.1. Processing Non-ASCII Strings . . . . . . . . . . . . . . . 14
6.2. DNSSEC Authentication of IDN Domain Names . . . . . . . . 14 6.2. DNSSEC Authentication of IDN Domain Names . . . . . . . . 14
6.3. Root and other DNS Server Considerations . . . . . . . . . 15 6.3. Root and other DNS Server Considerations . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Summary of Major Changes from IDNA2003 . . . . . . . 19 Appendix A. Summary of Major Changes from IDNA2003 . . . . . . . 19
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20
B.1. Changes between Version -00 and -01 of B.1. Changes between Version -00 and -01 of
draft-ietf-idnabis-protocol . . . . . . . . . . . . . . . 20 draft-ietf-idnabis-protocol . . . . . . . . . . . . . . . 20
B.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 20 B.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 20
B.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 20 B.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 21
B.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 21 B.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 21
B.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 21 B.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 21
B.6. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 21 B.6. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 B.7. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
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 A 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
skipping to change at page 4, line 37 skipping to change at page 4, line 37
into fully-qualified domain names and parsing labels out of those into fully-qualified domain names and parsing labels out of those
names are covered in the base DNS standards [RFC1034] [RFC1035] and names are covered in the base DNS standards [RFC1034] [RFC1035] and
their various updates. An application may, of course, apply locally- their various updates. An application may, of course, apply locally-
appropriate conventions to the presentation forms of domain names as appropriate conventions to the presentation forms of domain names as
discussed in [IDNA2008-Rationale]. discussed in [IDNA2008-Rationale].
While they share terminology, reference data, and some operations, While they share terminology, reference data, and some operations,
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). registration (Section 4) and one for IDN lookup (Section 5).
A good deal of the background material that appeared in RFC 3490
[RFC3490] has been removed from this update. That material is either
of historical interest only or has been covered from a more recent
perspective in RFC 4690 [RFC4690] and [IDNA2008-Rationale].
[[anchor2: This paragraph is not normative and not required to
understand this spec. It will be removed in version -07 unless
someone provides a convincing rationale for retaining it.]]
1.1. Discussion Forum 1.1. Discussion Forum
[[anchor4: RFC Editor: please remove this section.]] [[anchor3: 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
General terminology applicable to IDNA, but with meanings familiar to General terminology applicable to IDNA, but with meanings familiar to
those who have worked with Unicode or other character set standards those who have worked with Unicode or other character set standards
and the DNS, appears in [IDNA2008-Defs]. Terminology that is an and the DNS, appears in [IDNA2008-Defs]. Terminology that is an
integral, normative, part of the IDNA definition, including the integral, normative, part of the IDNA definition, including the
skipping to change at page 5, line 29 skipping to change at page 5, line 20
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 conformance means adherence to the following requirements: IDNA conformance means adherence to 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-Rationale]), it MUST contain slot (see Section 2 and [IDNA2008-Defs]), it MUST contain only
only ASCII characters (i.e., must be either an A-label or an LDH- ASCII characters (i.e., must be either an A-label or an LDH-
label), or must be a label associated with a DNS application that label), or must be a label associated with a DNS application that
is not subject to either IDNA or the historical recommendations is not subject to either IDNA or the historical recommendations
for "hostname"-style names [RFC1034]. for "hostname"-style names [RFC1034].
2. Comparison of labels SHOULD be done on the A-label form, using an 2. Comparison of labels MUST be done on equivalent forms: either
ASCII case-insensitive comparison as with all comparisons of DNS both A-Label forms or both U-Label forms. Because A-labels and
labels. Because A-labels and U-labels can be transformed into U-labels can be transformed into each other without loss of
each other without loss of information, comparison of native information, these comparisons are equivalent. However, when the
character labels is possible if the application first carefully A-label form is compared, it MUST use an ASCII case-insensitive
verifies that the strings are U-labels. comparison as with all comparisons of DNS labels. Comparison is
only valid if the putative labels have been verified to be either
A-Labels or U-Labels.
3. Labels being registered MUST conform to the requirements of 3. Labels being registered MUST conform to the requirements of
Section 4. Labels being looked up and the lookup process MUST Section 4. Labels being looked up and the lookup process MUST
conform to the requirements of Section 5. conform to the requirements of Section 5.
3.2. Applicability 3.2. Applicability
IDNA is applicable to all domain names in all domain name slots IDNA is applicable to all domain names in all domain name slots
except where it is explicitly excluded. It is not applicable to except where it is explicitly excluded. It is not applicable to
domain name slots which do not use the LDH syntax rules. domain name slots which do not use the LDH syntax rules.
This implies that IDNA is applicable to many protocols that predate This implies that IDNA is applicable to many protocols that predate
IDNA. Note that IDNs occupying domain name slots in those older IDNA. Note that IDNs occupying domain name slots in those older
protocols MUST be in A-label form until and unless those protocols protocols MUST be in A-label form until and unless those protocols
and implementations of them are upgraded and that IDNs actually and implementations of them are upgraded to be IDN-aware and that
appearing in DNS queries or responses MUST be in A-label form. IDNs actually appearing in DNS queries or responses MUST be in
A-label form.
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. resource records whose CLASS is IN.
There are currently no other exclusions on the applicability of IDNA There are currently no other exclusions on the applicability of IDNA
to DNS resource records. Applicability depends entirely on the to DNS resource records. Applicability depends entirely on the
CLASS, and not on the TYPE except as noted below. This will remain CLASS, and not on the TYPE except as noted below. This will remain
true, even as new types are defined, unless there is a compelling true, even as new types are defined, unless there is a compelling
skipping to change at page 7, line 18 skipping to change at page 7, line 12
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. Proposed label 4.1. Proposed label
The registrant submits a request for an IDN. The user typically The registrant submits a request for an IDN. The user typically
produces the request string by the keyboard entry of a character produces the request string by the keyboard entry of a character
sequence in the local native character set (which might, of course, sequence in the local native character set (which might, of course,
be Unicode). be Unicode).
The registry MAY permit submission of labels in A-label form. If it
does so, it SHOULD perform a conversion to a U-label, perform the
steps and tests described below, and verify that the A-label produced
by the step in Section 4.5 matches the one provided as input. If,
for some reason, it does not, the registration MUST be rejected. If
the conversion to a U-label is not performed, the registry MUST
verify that the A-label is superficially valid, i.e., that it does
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. Invalid strings that
appear to be A-labels MUST NOT be placed in DNS zones.
[[anchor9: Editorial: Should the sentences starting with "The
registry" be moved to 4.3? I.e., would they be more in sequence
there? Note that A-labels are, by definition, in ASCII, so section
4.2 does not apply to them. The tone of this recommendation also
seems slightly at odds with the statements at the end of 4.2.
Suggested text for cleaning this up, harmonizing it, and reducing
redundancy would be appreciated.]]
4.2. Conversion to Unicode and Normalization 4.2. Conversion to Unicode and Normalization
Some system routine, or a localized front-end to the IDNA process, Some system routine, or a localized front-end to the IDNA process,
ensures that the proposed label is a Unicode string or converts it to ensures that the proposed label is a Unicode string or converts it to
one as appropriate. That string MUST be in Unicode Normalization one as appropriate. Independent of its source form, the string MUST
Form C (NFC [Unicode-UAX15]). be in Unicode Normalization Form C (NFC [Unicode-UAX15]) before
further processing in this protocol.
As a local implementation choice, the implementation MAY choose to As a local implementation choice, the implementation MAY choose to
map some forbidden characters to permitted characters (for instance map some forbidden characters to permitted characters (for instance
mapping uppercase characters to lowercase ones), displaying the mapping uppercase characters to lowercase ones), displaying the
result to the user, and allowing processing to continue. However, it result to the user, and allowing processing to continue. This should
is strongly recommended that, to avoid any possible ambiguity, be done very conservatively to prevent interoperability problems with
entities responsible for zone files ("registries") accept lookup applications that do not follow exactly the same rules. In
particular, it is strongly recommended that, to avoid any possible
ambiguity, entities responsible for zone files ("registries") accept
registrations only for A-labels (to be converted to U-labels by the registrations only for A-labels (to be converted to U-labels by the
registry as discussed above) or U-labels actually produced from registry as discussed above) or U-labels actually produced from
A-labels, not forms expected to be converted by some other process. A-labels, not forms expected to be converted by some other process.
4.3. Permitted Character and Label Validation 4.3. Permitted Character and Label Validation
4.3.1. Rejection of Characters that are not Permitted 4.3.1. Input Format
The Unicode string is checked to verify that no characters that IDNA [[anchor8: Note in -07 -- this section was formerly the second
does not permit in input appear in it. Those characters are paragraph of Section 4.1. It may need additional work; suggestions
welcome.]]
The registry MAY permit submission of labels in A-label form. If it
does so, it MUST perform a conversion to a U-label, perform the steps
and tests described below, and verify that the A-label produced by
the step in Section 4.5 matches the one provided as input. If, for
some reason, it does not, the registration MUST be rejected. If the
conversion to a U-label is not performed, the registry MUST verify
that the A-label is superficially valid, i.e., that it does 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. Invalid strings that
appear to be A-labels MUST NOT be placed in DNS zones.
4.3.2. Rejection of Characters that are not Permitted
The candidate Unicode string is checked to verify that characters
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.
4.3.2. Label Validation 4.3.3. Label Validation
The proposed label (in the form of a Unicode string, i.e., a putative The proposed label (in the form of a Unicode string, i.e., a putative
U-label) is then examined, performing tests that require examination U-label) is then examined, performing tests that require examination
of more than one character. of more than one character.
4.3.2.1. Rejection of Confusing or Hostile Sequences in U-labels 4.3.3.1. Rejection of Hyphen Sequences in U-labels
The Unicode string MUST NOT contain "--" (two consecutive hyphens) in The Unicode string MUST NOT contain "--" (two consecutive hyphens) in
the third and fourth character positions. the third and fourth character positions when the label is considered
in "on the wire" order.
4.3.2.2. Leading Combining Marks 4.3.3.2. Leading Combining Marks
The first character of the string is examined to verify that it is The first character of the string (when the label is considered in
not a combining mark. If it is a combining mark, the string MUST NOT "on the wire" order) is examined to verify that it is not a combining
be registered. mark. If it is a combining mark, the string MUST NOT be registered.
4.3.2.3. Contextual Rules 4.3.3.3. Contextual Rules
Each code point is checked for its identification as a character Each code point is checked for its identification as a character
requiring contextual processing for registration (the list of requiring contextual processing for registration (the list of
characters appears as the combination of CONTEXTJ and CONTEXTO in characters appears as the combination of CONTEXTJ and CONTEXTO in
[IDNA2008-Tables] as do the contextual rules themselves). If that [IDNA2008-Tables] as do the contextual rules themselves). If that
indication appears, the table of contextual rules is checked for a indication appears, the table of contextual rules is checked for a
rule for that character. If no rule is found, the proposed label is rule for that character. If no rule is found, the proposed label is
rejected and MUST NOT be installed in a zone file. If one is found, rejected and MUST NOT be installed in a zone file. If one is found,
it is applied (typically as a test on the entire label or on adjacent it is applied (typically as a test on the entire label or on adjacent
characters within the label). If the application of the rule does characters within the label). If the application of the rule does
not conclude that the character is valid in context, the proposed not conclude that the character is valid in context, the proposed
label MUST BE rejected. (See the IANA Considerations: IDNA Context label MUST BE rejected. (See the IANA Considerations: IDNA Context
Registry section of [IDNA2008-Tables].) Registry section of [IDNA2008-Tables].)
These contextual rules are required to permit the use of characters These contextual rules are required to support the use of characters
that would otherwise risk causing considerable harm. For example, that could be used, under other conditions, to produce misleading
labels containing invisible ("zero-width") characters may be labels or to cause unacceptable ambiguity in label matching and
permitted in context with characters whose presentation forms are interpretation. For example, labels containing invisible ("zero-
significantly changed by the presence or absence of the zero-width width") characters may be permitted in context with characters whose
characters, while other labels in which zero-width characters appear presentation forms are significantly changed by the presence or
may be rejected. absence of the zero-width characters, while other labels in which
[[anchor14: Should this paragraph be removed? Note that I've been zero-width characters appear may be rejected.
strongly encouraged to supply specific examples to reduce abstraction
and questions about the appropriateness of the text. -JcK]]
4.3.2.4. Labels Containing Characters Written Right to Left 4.3.3.4. Labels Containing Characters Written Right to Left
Additional special tests for right-to-left strings are applied (See Additional special tests for right-to-left strings are applied.
[IDNA2008-BIDI]). Strings that contain right to left characters that Strings that contain right to left characters that do not conform to
do not conform to the rule(s) identified there MUST NOT be inserted the rule(s) identified in [IDNA2008-BIDI] MUST NOT be inserted as
as labels in zone files. labels in zone files.
4.3.3. Registration Validation Summary 4.3.4. Registration Validation Summary
Strings that have been produced by the steps above, and whose Strings that contain at least one non-ASCII character, have been
contents pass the above tests, are U-labels. produced by the steps above, whose contents pass the above tests, and
are 63 or fewer characters long in ACE form (see Section 4.5), are
U-labels.
To summarize, tests are made in Section 4.3 for invalid characters, To summarize, tests are made in Section 4.3 for invalid characters,
invalid combinations of characters, and for labels that are invalid invalid combinations of characters, and for labels that are invalid
even if the characters they contain are valid individually. even if the characters they contain are valid individually.
4.4. Registry Restrictions 4.4. 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
skipping to change at page 10, line 10 skipping to change at page 10, line 10
The string produced by the above steps is checked and processed as The string produced by the above steps is checked and processed as
appropriate to local registry restrictions. Application of those appropriate to local registry restrictions. Application of those
registry restrictions may result in the rejection of some labels or registry restrictions may result in the rejection of some labels or
the application of special restrictions to others. the application of special restrictions to others.
4.5. Punycode Conversion 4.5. Punycode Conversion
The resulting U-label is converted to an A-label. The A-label, more The resulting U-label is converted to an A-label. The A-label, more
precisely defined elsewhere, is the encoding of the U-label according precisely defined elsewhere, is the encoding of the U-label according
to the Punycode algorithm [RFC3492] with the ACE prefix "xn--" added to the Punycode algorithm [RFC3492] with the ACE prefix "xn--" added
at at the beginning of the string. This document updates RFC 3492 at the beginning of the string. This document updates RFC 3492 only
only to the extent of replacing the reference to the discussion of to the extent of replacing the reference to the discussion of the ACE
the ACE prefix. The ACE prefix is now specified in this document prefix. The ACE prefix is now specified in this document rather than
rather than as part of RFC 3490 or Nameprep [RFC3491]. as part of RFC 3490 or Nameprep [RFC3491] but is the same in both
sets of documents.
The failure conditions identified in the Punycode encoding procedure The failure conditions identified in the Punycode encoding procedure
cannot occur if the input is a U-label as determined by the steps cannot occur if the input is a U-label as determined by the steps
above. above.
4.6. Insertion in the Zone 4.6. Insertion in the Zone
The A-label is registered in the DNS by insertion into a zone. The A-label is registered in the DNS by insertion into a zone.
5. Domain Name Lookup Protocol 5. Domain Name Lookup Protocol
skipping to change at page 13, line 8 skipping to change at page 13, line 8
table [IDNA2008-Tables]. table [IDNA2008-Tables].
o Labels containing code points that are shown in the permitted o Labels containing code points that are shown in the permitted
character table as requiring a contextual rule and that are character table as requiring a contextual rule and that are
flagged as requiring exceptional special processing on lookup flagged as requiring exceptional special processing on lookup
("CONTEXTJ" in the Tables) but do not conform to that rule. ("CONTEXTJ" in the Tables) but do not conform to that rule.
o Labels containing other code points that are shown in the o Labels containing other code points that are shown in the
permitted character table as requiring a contextual rule permitted character table as requiring a contextual rule
("CONTEXTO" in the tables), but for which no such rule appears in ("CONTEXTO" in the tables), but for which no such rule appears in
the table of rules. With the exception in the rule immediately the table of rules. Applications resolving DNS names or carrying
above, applications resolving DNS names or carrying out equivalent out equivalent operations are not required to test contextual
operations are not required to test contextual rules, only to rules for "CONTEXTO" characters, only to verify that a rule exists
verify that a rule exists. (although they MAY make such tests to give better information to
the user).
o Labels whose first character is a combining mark. o Labels whose first character is a combining mark.
In addition, the application SHOULD apply the following test. The In addition, the application SHOULD apply the following test. The
test may be omitted in special circumstances, such as when the lookup test may be omitted in special circumstances, such as when the lookup
application knows that the conditions are enforced elsewhere, because application knows that the conditions are enforced elsewhere, because
an attempt to look up and resolve such strings will almost certainly an attempt to look up and resolve such strings will almost certainly
lead to a DNS lookup failure except when wildcards are present in the lead to a DNS lookup failure except when wildcards are present in the
zone. However, applying the test is likely to give much better zone. However, applying the test is likely to give much better
information about the reason for a lookup failure -- information that information about the reason for a lookup failure -- information that
may be usefully passed to the user when that is feasible -- then DNS may be usefully passed to the user when that is feasible -- than DNS
resolution failure information alone. In any event, lookup resolution failure information alone. In any event, lookup
applications should avoid attempting to resolve labels that are applications should avoid attempting to resolve labels that are
invalid under that test. invalid under that test.
o Verification that the string is compliant with the requirements o Verification that the string is compliant with the requirements
for right to left characters, specified in [IDNA2008-BIDI]. for right to left characters, specified in [IDNA2008-BIDI].
For all other strings, the lookup application MUST rely on the For all other strings, the lookup application MUST rely on the
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 above rules and declines to process a string that conforms to the rules above and
look it up in the DNS is not in conformance with this protocol. does not look it up in the DNS is not in conformance with this
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, a U-label, is converted to an A-label using the
Punycode algorithm with the ACE prefix added. Punycode algorithm with the ACE prefix added.
5.7. DNS Name Resolution 5.7. DNS Name Resolution
The A-label is looked up in the DNS, using normal DNS resolver The A-label is looked up in the DNS, using normal DNS resolver
procedures. procedures.
6. Name Server Considerations 6. Name Server Considerations
[[anchor18: Note in draft: If we really want this document to contain [[anchor16: Note in draft: If we really want this document to contain
only information that is necessary to proper implementation of IDNA only information that is necessary to proper implementation of IDNA
by implementers who are familiar with the DNS, the material in this by implementers who are familiar with the DNS, the material in this
section is either tutorial, explanatory, or totally unnecessary. section is either tutorial, explanatory, or totally unnecessary.
Should some or all of it be moved back to Rationale?]] Should some or all of it be moved back to Rationale?]]
6.1. Processing Non-ASCII Strings 6.1. Processing Non-ASCII Strings
Existing DNS servers do not know the IDNA rules for handling non- Existing DNS servers do not know the IDNA rules for handling non-
ASCII forms of IDNs, and therefore need to be shielded from them. ASCII forms of IDNs, and therefore need to be shielded from them.
All existing channels through which names can enter a DNS server All existing channels through which names can enter a DNS server
skipping to change at page 14, line 45 skipping to change at page 14, line 50
DNS Security [RFC2535] is a method for supplying cryptographic DNS Security [RFC2535] is a method for supplying cryptographic
verification information along with DNS messages. Public Key verification information along with DNS messages. Public Key
Cryptography is used in conjunction with digital signatures to Cryptography is used in conjunction with digital signatures to
provide a means for a requester of domain information to authenticate provide a means for a requester of domain information to authenticate
the source of the data. This ensures that it can be traced back to a the source of the data. This ensures that it can be traced back to a
trusted source, either directly or via a chain of trust linking the trusted source, either directly or via a chain of trust linking the
source of the information to the top of the DNS hierarchy. source of the information to the top of the DNS hierarchy.
IDNA specifies that all internationalized domain names served by DNS IDNA specifies that all internationalized domain names served by DNS
servers that cannot be represented directly in ASCII must use the servers that cannot be represented directly in ASCII MUST use the
A-label form. Conversion to A-labels must be performed prior to a A-label form. Conversion to A-labels MUST be performed prior to a
zone being signed by the private key for that zone. Because of this zone being signed by the private key for that zone. Because of this
ordering, it is important to recognize that DNSSEC authenticates a ordering, it is important to recognize that DNSSEC authenticates a
domain name containing A-labels or conventional LDH-labels, not domain name containing A-labels or conventional LDH-labels, not
U-labels. In the presence of DNSSEC, no form of a zone file or query U-labels. In the presence of DNSSEC, no form of a zone file or query
response that contains a U-label may be signed or the signature response that contains a U-label may be signed or the signature
validated. validated.
One consequence of this for sites deploying IDNA in the presence of One consequence of this for sites deploying IDNA in the presence of
DNSSEC is that any special purpose proxies or forwarders used to DNSSEC is that any special purpose proxies or forwarders used to
transform user input into IDNs must be earlier in the lookup flow transform user input into IDNs must be earlier in the lookup flow
skipping to change at page 16, line 45 skipping to change at page 16, line 48
This revision to IDNA would have been impossible without the This revision to IDNA would have been impossible without the
accumulated experience since RFC 3490 was published and resulting accumulated experience since RFC 3490 was published and resulting
comments and complaints of many people in the IETF, ICANN, and other comments and complaints of many people in the IETF, ICANN, and other
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, Mark suggestions from the other contributors, Stephane Bortzmeyer, Vint
Davis, Paul Hoffman, Kent Karlsson, Erik van der Poel, Marcos Sanz, Cerf, Mark Davis, Paul Hoffman, Kent Karlsson, Erik van der Poel,
Andrew Sullivan, Ken Whistler, and other WG participants. Special Marcos Sanz, Andrew Sullivan, Ken Whistler, and other WG
thanks are due to Paul Hoffman for permission to extract material participants. Special thanks are due to Paul Hoffman for permission
from his Internet-Draft to form the basis for Appendix A to extract material from his Internet-Draft to form the basis for
Appendix A
11. References 11. References
11.1. Normative References 11.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 20, line 6 skipping to change at page 20, line 12
Unicode properties plus a small exclusion list created by Unicode properties plus a small exclusion list created by
humans". humans".
6. Introduce the new concept of characters that can be used only in 6. Introduce the new concept of characters that can be used only in
specific contexts. specific contexts.
7. Allow typical words and names in languages such as Dhivehi and 7. Allow typical words and names in languages such as Dhivehi and
Yiddish to be expressed. Yiddish to be expressed.
8. Make bidirectional domain names (delimited strings of labels, 8. Make bidirectional domain names (delimited strings of labels,
not just labels standing on their own) display in a non- 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 B. Change Log
[[anchor27: RFC Editor: Please remove this appendix.]] [[anchor25: RFC Editor: Please remove this appendix.]]
B.1. Changes between Version -00 and -01 of draft-ietf-idnabis-protocol B.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 B.2. Version -02
skipping to change at page 21, line 39 skipping to change at page 21, line 48
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
o Multiple small textual and editorial changes and clarifications.
o Requirement for normalization clarified to apply to all cases and
conditions for preprocessing further clarified.
o Substantive change to Section 4.3.1, turning a SHOULD to a MUST
(see note from Mark Davis, 19 November, 2008 18:14 -0800).
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. 39 change blocks. 
105 lines changed or deleted 119 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/