draft-ietf-idnabis-protocol-13.txt   draft-ietf-idnabis-protocol-14.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: January 13, 2010 Expires: February 10, 2010
Internationalized Domain Names in Applications (IDNA): Protocol Internationalized Domain Names in Applications (IDNA): Protocol
draft-ietf-idnabis-protocol-13.txt draft-ietf-idnabis-protocol-14.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 January 13, 2010. This Internet-Draft will expire on February 10, 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 22 skipping to change at page 3, line 22
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 . . . . 8
4.2.3. Label Validation . . . . . . . . . . . . . . . . . . . 8 4.2.3. Label Validation . . . . . . . . . . . . . . . . . . . 8
4.2.4. Registration Validation Summary . . . . . . . . . . . 9 4.2.4. Registration Validation Summary . . . . . . . . . . . 9
4.3. Registry Restrictions . . . . . . . . . . . . . . . . . . 10 4.3. Registry Restrictions . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . 10
5.2. Conversion to Unicode . . . . . . . . . . . . . . . . . . 11 5.2. Conversion to Unicode . . . . . . . . . . . . . . . . . . 11
5.3. Character Changes in Preprocessing or the User 5.3. A-label Input . . . . . . . . . . . . . . . . . . . . . . 11
Interface . . . . . . . . . . . . . . . . . . . . . . . . 11 5.4. Validation and Character List Testing . . . . . . . . . . 11
5.4. A-label Input . . . . . . . . . . . . . . . . . . . . . . 12 5.5. Punycode Conversion . . . . . . . . . . . . . . . . . . . 13
5.5. Validation and Character List Testing . . . . . . . . . . 13 5.6. DNS Name Resolution . . . . . . . . . . . . . . . . . . . 13
5.6. Punycode Conversion . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5.7. DNS Name Resolution . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 Appendix A. Summary of Major Changes from IDNA2003 . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 17 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Local Mapping Alternatives . . . . . . . . . . . . . 18 B.1. Changes between Version -00 and -01 of
A.1. Transitional Mapping Model . . . . . . . . . . . . . . . . 19 draft-ietf-idnabis-protocol . . . . . . . . . . . . . . . 18
A.1.1. Fallback Lookup . . . . . . . . . . . . . . . . . . . 19 B.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 18
A.1.2. Two-step Lookup . . . . . . . . . . . . . . . . . . . 20 B.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 18
A.2. Internationalized Resource Identifier (IRI) Mapping B.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 19
Model . . . . . . . . . . . . . . . . . . . . . . . . . . 20 B.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 19
Appendix B. Summary of Major Changes from IDNA2003 . . . . . . . 21 B.6. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 19
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 22 B.7. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 19
C.1. Changes between Version -00 and -01 of B.8. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 19
draft-ietf-idnabis-protocol . . . . . . . . . . . . . . . 22 B.9. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 20
C.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 22 B.10. Version -10 . . . . . . . . . . . . . . . . . . . . . . . 20
C.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 22 B.11. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 21
C.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 23 B.12. Version -12 . . . . . . . . . . . . . . . . . . . . . . . 21
C.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 23 B.13. Version -13 . . . . . . . . . . . . . . . . . . . . . . . 21
C.6. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 23 B.14. Version -14 . . . . . . . . . . . . . . . . . . . . . . . 22
C.7. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
C.8. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 24
C.9. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 24
C.10. Version -10 . . . . . . . . . . . . . . . . . . . . . . . 24
C.11. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 25
C.12. Version -12 . . . . . . . . . . . . . . . . . . . . . . . 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 A 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
material and advice to zone administrators who support IDNs is material and advice to zone administrators who support IDNs is
provided in another documents, notably [IDNA2008-Rationale]. provided in another document, [IDNA2008-Rationale].
IDNA works by allowing applications to use certain ASCII string IDNA works by allowing applications to use certain ASCII string
labels (beginning with a special prefix) to represent non-ASCII name labels (beginning with a special prefix) to represent non-ASCII name
labels. Lower-layer protocols need not be aware of this; therefore labels. Lower-layer protocols need not be aware of this; therefore
IDNA does not changes any infrastructure. In particular, IDNA does IDNA does not changes any infrastructure. In particular, IDNA does
not depend on any changes to DNS servers, resolvers, or protocol not depend on any changes to DNS servers, resolvers, or protocol
elements, because the ASCII name service provided by the existing DNS elements, because the ASCII name service provided by the existing DNS
can be used for IDNA. can be used for IDNA.
IDNA applies only to DNS labels. The base DNS standards [RFC1034] IDNA applies only to DNS labels. The base DNS standards [RFC1034]
skipping to change at page 9, line 26 skipping to change at page 9, line 26
4.2.3.3. Contextual Rules 4.2.3.3. Contextual Rules
The Unicode string MUST NOT contain any characters whose validity is The Unicode string MUST NOT contain any characters whose validity is
context-dependent, unless the validity is positively confirmed by a context-dependent, unless the validity is positively confirmed by a
contextual rule. To check this, each code-point marked as CONTEXTJ contextual rule. To check this, each code-point marked as CONTEXTJ
and CONTEXTO in [IDNA2008-Tables] MUST have a non-null rule. If such and CONTEXTO in [IDNA2008-Tables] MUST have a non-null rule. If such
a code-point is missing a rule, it is invalid. If the rule exists a code-point is missing a rule, it is invalid. If the rule exists
but the result of applying the rule is negative or inconclusive, the but the result of applying the rule is negative or inconclusive, the
proposed label is invalid. proposed label is invalid.
NOTE: These contextual rules are required to support characters that
could be used, under some conditions, to produce misleading labels or
to cause unacceptable ambiguity in label matching and interpretation.
For example, labels containing zero-width characters may be permitted
in context with characters whose presentation forms are significantly
changed by the zero-width characters, while other labels in which
zero-width characters appear may be rejected.
[[anchor11: Note in draft: Should this note be moved to Rationale???
It has no normative consequences here.]]
4.2.3.4. Labels Containing Characters Written Right to Left 4.2.3.4. Labels Containing Characters Written Right to Left
If the proposed label contains any characters that are written from If the proposed label contains any characters that are written from
right to left it MUST meet the "bidi" criteria [IDNA2008-BIDI]. right to left it MUST meet the "bidi" criteria [IDNA2008-BIDI].
4.2.4. Registration Validation Summary 4.2.4. Registration Validation 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 all of the tests in produced by the steps above, whose contents pass all of the tests in
Section 4.2, and are 63 or fewer characters long in ACE form (see Section 4.2, and are 63 or fewer characters long in ACE form (see
skipping to change at page 10, line 16 skipping to change at page 10, line 6
In addition to the rules and tests above, there are many reasons why In addition to the rules and tests above, there are many reasons why
a registry could reject a label. Registries at all levels of the a registry could reject a label. Registries at all levels of the
DNS, not just the top level, establish policies about label DNS, not just the top level, establish policies about label
registrations. Policies are likely to be informed by the local registrations. Policies are likely to be informed by the local
languages and may depend on many factors including what characters languages and may depend on many factors including what characters
are in the label (for example, a label may be rejected based on other are in the label (for example, a label may be rejected based on other
labels already registered). See [IDNA2008-Rationale] for a labels already registered). See [IDNA2008-Rationale] for a
discussion and recommendations about registry policies. discussion and recommendations about registry policies.
The string produced by the above steps is checked and processed as The string produced by the steps in Section 4.2 is checked and
appropriate to local registry restrictions. Application of those processed as appropriate to local registry restrictions. Application
registry restrictions may result in the rejection of some labels or of those registry restrictions may result in the rejection of some
the application of special restrictions to others. labels or the application of special restrictions to others.
4.4. Punycode Conversion 4.4. 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 (defined in
precisely defined elsewhere, is the encoding of the U-label according [IDNA2008-Defs] [[anchor13: Insert section number]]). The A-label is
to the Punycode algorithm [RFC3492] with the ACE prefix "xn--" added the encoding of the U-label according to the Punycode algorithm
at the beginning of the string. The resulting string must, of [RFC3492] with the ACE prefix "xn--" added at the beginning of the
course, conform to the length limits imposed by the DNS. This string. The resulting string must, of course, conform to the length
document updates RFC 3492 only to the extent of replacing the limits imposed by the DNS. This document updates RFC 3492 only to
reference to the discussion of the ACE prefix. The ACE prefix is now the extent of replacing the reference to the discussion of the ACE
specified in this document rather than as part of RFC 3490 or prefix. The ACE prefix is now specified in this document rather than
Nameprep [RFC3491] but is the same in both sets of documents. 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.5. Insertion in the Zone 4.5. 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
Lookup is different from registration and different tests are applied Lookup is different from registration and different tests are applied
on the client. Although some validity checks are necessary to avoid on the client. Although some validity checks are necessary to avoid
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 described in Section 5.2 are required.
[[anchor14: Note in Draft: Try to reorganize and renumber Section 5
(Lookup) so that it exactly parallels Section 4 (Registration). This
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
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. matters, to be accomplished prior to actual invocation of IDNA.
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. Depending on local needs, this conversion
normalization as discussed in Section 4.1. The result MUST be a may involve mapping some characters into other characters as well as
Unicode string in NFC form. coding conversions. Those issues are discussed in [IDNA2008-Mapping]
and the mapping-related sections of [IDNA2008-Rationale]. [[anchor14:
5.3. Character Changes in Preprocessing or the User Interface Supply section number.]] A Unicode string may require normalization
as discussed in Section 4.1. The result MUST be a Unicode string in
[[anchor15: Note in Draft -13. This entire section is likely to need NFC form.
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
user expectations. For instance, it might be reasonable, at 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
approached with caution due to some edge cases: in the long term, it
is probably better for users to understand IDNs strictly in lower-
case, U-label, form. More generally, preprocessing may be useful to
smooth the transition from IDNA2003, especially for direct user
input, but with similar cautions. In general, IDNs appearing in
files and those transmitted across the network as part of protocols
are expected to be in either ASCII form (including A-labels) or to
contain U-labels, rather than being in forms requiring mapping or
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,
especially to direct user input, at this point. They include
interpreting various characters as separating domain name components
from each other (label separators) because they either look like
periods or are used to separate sentences, mapping halfwidth or
fullwidth East Asian characters to the common form permitted in
labels, or giving special treatment to characters whose presentation
forms are dependent only on placement in the label. Such
localization changes are also outside the scope of this
specification.
Recommendations for preprocessing for global contexts (i.e., when
local considerations do not apply or cannot be used) and for maximum
interoperability with labels that might have been specified under
liberal readings of IDNA2003 are given in [IDNA2008-Rationale]. It
is important to note that the intent of these specifications is that
labels in application protocols, files, or links are intended to be
in U-label or A-label form. Preprocessing MUST NOT map a character
that is valid in a label as specified elsewhere in this document or
in [IDNA2008-Tables] into another character. Excessively liberal use
of preprocessing, especially to strings stored in files, poses a
threat to consistent and predictable behavior for the user even if
not to actual interoperability.
Because these transformations are local, it is important that domain
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
a consequence of this step. This step is not standardized as part of
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.3. A-label Input
If the input to this procedure appears to be an A-label (i.e., it If the input to this procedure appears to be an A-label (i.e., it
starts in "xn--"), the lookup application MAY attempt to convert it starts in "xn--"), 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.4 and the conversion of
Section 5.6 to that form. If the label is converted to Unicode Section 5.5 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
[IDNA2008-Rationale] for additional discussion on this topic. [IDNA2008-Rationale] for additional discussion on this topic.
That conversion and testing SHOULD be performed if the domain name That conversion and testing SHOULD be performed if the domain name
will later be presented to the user in native character form (this will later be presented to the user in native character form (this
requires that the lookup application be IDNA-aware). If those steps requires that the lookup application be IDNA-aware). If those steps
are not performed, the lookup process SHOULD at least make tests to are not performed, the lookup process SHOULD at least make tests to
determine that the string is actually an A-label, examining it for determine that the string is actually an A-label, examining it for
the invalid formats specified in the Punycode decoding specification. the invalid formats specified in the Punycode decoding specification.
Applications that are not IDNA-aware will obviously omit that Applications that are not IDNA-aware will obviously omit that
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.4. 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. Labels that have not been fully evaluated than the registration one. Labels that have not been fully evaluated
for conformance to the applicable rules are referred to as "putative" for conformance to the applicable rules are referred to as "putative"
labels as discussed in [IDNA2008-Defs][[anchor16: ??? Insert section labels as discussed in [IDNA2008-Defs][[anchor15: ??? Insert section
number -- 2.2.3 as of Defs-09]]. Putative labels with any of the number -- 2.2.3 as of Defs-09]]. Putative labels with any of the
following characteristics MUST BE rejected prior to DNS lookup: 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 "--" (two consecutive hyphens) in the third and
fourth character positions.
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].
o Labels containing code points that are identified in o Labels containing code points that are identified in
[IDNA2008-Tables] as "CONTEXTJ", i.e., requiring exceptional [IDNA2008-Tables] as "CONTEXTJ", i.e., requiring exceptional
contextual rule processing on lookup, but that do not conform to contextual rule processing on lookup, but that do not conform to
that rule. Note that this implies that a rule much be defined, that rule. Note that this implies that a rule must be defined,
not null: a character that requires a contextual rule but for not null: a character that requires a contextual rule but for
which the rule is null is treated in this step as having failed to which the rule is null is treated in this step as having failed to
conform to the rule. conform to the rule.
o Labels containing code points that are identified in o Labels containing code points that are identified in
[IDNA2008-Tables] as "CONTEXTO", but for which no such rule [IDNA2008-Tables] as "CONTEXTO", but for which no such rule
appears in the table of rules. Applications resolving DNS names appears in the table of rules. Applications resolving DNS names
or carrying out equivalent operations are not required to test or carrying out equivalent operations are not required to test
contextual rules for "CONTEXTO" characters, only to verify that a contextual rules for "CONTEXTO" characters, only to verify that a
rule is defined (although they MAY make such tests to provide rule is defined (although they MAY make such tests to provide
better protection or give better information to the user). better protection or give better information to the user).
o Labels whose first character is a combining mark (see o Labels whose first character is a combining mark (see
Section 4.2.3.2). Section 4.2.3.2).
In addition, the application SHOULD apply the following test. The In addition, the application SHOULD apply the following test.
test may be omitted in special circumstances, such as when the lookup
application knows that the conditions are enforced elsewhere, because
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
zone. However, applying the test is likely to give much better
information about the reason for a lookup failure -- information that
may be usefully passed to the user when that is feasible -- than DNS
resolution failure information alone. In any event, lookup
applications should avoid attempting to resolve labels that are
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].
This test may be omitted in special circumstances, such as when the
lookup application knows that the conditions are enforced elsewhere,
because 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 zone. However, applying the test is likely to give
much better information about the reason for a lookup failure --
information that may be usefully passed to the user when that is
feasible -- than DNS resolution failure information alone. In any
event, lookup applications should avoid attempting to resolve labels
that are invalid under that test.
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. While a lookup application their possible validity is not relevant. While a lookup application
may reasonably issue warnings about strings it believes may be may reasonably issue warnings about strings it believes may be
problematic, applications that decline to process a string that problematic, applications that decline to process a string that
conforms to the rules above (i.e., does not look it up in the DNS) conforms to the rules above (i.e., does not look it up in the DNS)
are not in conformance with this protocol. are not in conformance with this protocol.
5.6. Punycode Conversion 5.5. Punycode Conversion
The string that has now been validated for lookup is converted to ACE The string that has now been validated for lookup is converted to ACE
form using the Punycode algorithm (with the ACE prefix added). With form using the Punycode algorithm (with the ACE prefix added). With
the understanding that this summary is not normative (the steps above the understanding that this summary is not normative (the steps above
are), the string is either are), the string is either
o in Unicode NFC form that contains no leading combining marks, o in Unicode NFC form that contains no leading combining marks,
contains no DISALLOWED or UNASSIGNED code points, has rules contains no DISALLOWED or UNASSIGNED code points, has rules
associated with any code points in CONTEXTJ or CONTEXTO, and, for associated with any code points in CONTEXTJ or CONTEXTO, and, for
those in CONTEXTJ, to satisfies the conditions of the rules; or those in CONTEXTJ, to satisfies the conditions of the rules; or
o in A-label form, was supplied under circumstances in which the o in A-label form, was supplied under circumstances in which the
U-label conversions and tests have not been performed (see U-label conversions and tests have not been performed (see
Section 5.4). Section 5.3).
5.7. DNS Name Resolution 5.6. DNS Name Resolution
That resulting validated string is looked up in the DNS, using normal That resulting validated string is looked up in the DNS, using normal
DNS resolver procedures. That lookup can obviously either succeed DNS resolver procedures. That lookup can obviously either succeed
(returning information) or fail. (returning information) or fail.
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
skipping to change at page 16, line 9 skipping to change at page 14, line 33
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, Vint suggestions from the other contributors, Stephane Bortzmeyer, Vint
Cerf, Lisa Dusseault, Mark Davis, Paul Hoffman, Kent Karlsson, Erik Cerf, Lisa Dusseault, Mark Davis, Paul Hoffman, Kent Karlsson, Erik
van der Poel, Marcos Sanz, Andrew Sullivan, Ken Whistler, and other van der Poel, Marcos Sanz, Andrew Sullivan, Wil Tan, Ken Whistler,
WG participants. Special thanks are due to Paul Hoffman for and other WG participants. As is usual with IETF specifications,
permission to extract material from his Internet-Draft to form the while the document represents rough consensus, it should not be
basis for Appendix B. assumed that all participants and contributors agree with all
provisions. Special thanks are due to Paul Hoffman for permission to
extract material from his Internet-Draft to form the basis for
Appendix A.
10. References 10. References
10.1. Normative References 10.1. Normative References
[IDNA2008-BIDI] [IDNA2008-BIDI]
Alvestrand, H. and C. Karp, "An updated IDNA criterion for Alvestrand, H. and C. Karp, "An updated IDNA criterion for
right-to-left scripts", July 2008, <https:// right-to-left scripts", August 2009, <https://
datatracker.ietf.org/drafts/draft-ietf-idnabis-bidi/>. datatracker.ietf.org/drafts/draft-ietf-idnabis-bidi/>.
[IDNA2008-Defs] [IDNA2008-Defs]
Klensin, J., "Internationalized Domain Names for Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
February 2009, <https://datatracker.ietf.org/drafts/ August 2009, <https://datatracker.ietf.org/drafts/
draft-ietf-idnabis-defs/>. draft-ietf-idnabis-defs/>.
[IDNA2008-Tables] [IDNA2008-Tables]
Faltstrom, P., "The Unicode Codepoints and IDNA", Faltstrom, P., "The Unicode Codepoints and IDNA",
July 2008, <https://datatracker.ietf.org/drafts/ August 2009, <https://datatracker.ietf.org/drafts/
draft-ietf-idnabis-tables/>. draft-ietf-idnabis-tables/>.
A version of this document is available in HTML format at A version of this document is available in HTML format at
http://stupid.domain.name/idnabis/ http://stupid.domain.name/idnabis/
draft-ietf-idnabis-tables-02.html draft-ietf-idnabis-tables-02.html
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
skipping to change at page 17, line 38 skipping to change at page 16, line 17
[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] [IDNA2008-Mapping]
Resnick, P., "Mapping Characters in IDNA", July 2009, <htt Resnick, P., "Mapping Characters in IDNA", August 2009, <h
ps://datatracker.ietf.org/drafts/ ttps://datatracker.ietf.org/drafts/
draft-ietf-idnabis-mapping/>. 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)",
skipping to change at page 18, line 41 skipping to change at page 17, line 20
(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. Local Mapping Alternatives Appendix A. Summary of Major Changes from IDNA2003
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 the steps in one of the two subsections that immediately
follow.
A.1.1. Fallback Lookup
If the string validates and the resolution attempt in Section 5.7
successfully returns a result, the lookup process terminates with
that result. If validation succeeds but resolution fails, the
validated string is proceeded through the ToASCII operation specified
in IDNA2003 [RFC3490]. Assuming it produces a valid result, the
resulting string is compared to the previous validated one. If they
are not identical, a resolution attempt is made with the ToASCII
output and the result of that attempt is returned as the result of
the lookup operation.
Should IDNA2008 validation fail, the string is processed through
ToASCII and, assuming the result is valid, the resulting string is
resolved and the result of that attempt returned as the result of the
lookup operation.
If ToASCII (IDNA2003) conversion is attempted and fails, the lookup
operation behaves as if no name was found in the DNS.
Note that this procedure involves, at most, one DNS lookup
(resolution attempt). If IDNA2008 string validation, conversion, and
resolution succeed, no attempt is made to use IDNA2003 mechanisms.
The procedure does, however, require that lookup applications fully
support both IDNA2008 and IDNA2003 lookup operations so that the
fallback can occur.
A.1.2. Two-step Lookup
Prior to the resolution attempt in Section 5.7, ACE strings are
computed using both IDNA2003 (ToASCII) and IDNA2008 methods (as
specified here). Assuming both validate, those strings are compared.
If they are identical, or only one was valid, then a single DNS
resolution is performed and its result is the result of the lookup
operation. If both are valid but they are not identical, one
resolution attempt is made with each of the two ACE strings.
If neither string is valid as an IDN, then the lookup operation
fails.
When two resolutions are attempted, if one of the two is successful
and the other is not, the successful value is used as the result of
the lookup. If both are successful, the user or calling application
must be presented with a choice in some way.
This procedure will require two DNS lookups (resolution attempts) in
all cases except those in which the label string fails IDNA2008
validation, neither IDNA2003 or IDNA2008 can validate the string and
translate it to ACE form, or the strings obtained from the two
conversions are identical. As with the prior option, IDNA
implementations will need to support both the IDNA2003 algorithm and
tables and the IDNA2008 one. The question of how multiple results
from different interpretations of the same input string should be
handled by applications is a difficult one, with potential false
positive and security attack vector implications as well as the
possibility of general confusion.
In particular, 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 names are under the same control or not. From that
perspective, the approach in the previous subsection assumes that has
been done (if the IDNA2003-interpretation label is present at all)
while this one assumes that such bundling is unlikely to have
occurred.
[[anchor26: 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 22, line 16 skipping to change at page 18, line 11
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 C. Change Log Appendix B. Change Log
[[anchor29: RFC Editor: Please remove this appendix.]] [[anchor22: RFC Editor: Please remove this appendix.]]
C.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.
C.2. Version -02 B.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.
C.3. Version -03 B.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.
C.4. Version -04 B.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 (former Section 5.3 -- see
Appendix B.14) somewhat.
C.5. Version -05 B.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.3) per
note from Erik van der Poel. note from Erik van der Poel.
C.6. Version -06 B.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.
C.7. Version -07 B.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).
C.8. Version -08 B.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.
C.9. Version -09 B.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. Such mapping is now completely prohibited registration protocol. Such mapping is now completely prohibited
on Registration. on Registration.
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 B.10. Version -10
o Rewrote the registration input material slightly to further o Rewrote the registration input material slightly to further
clarify the "no mapping on registration" principle. clarify the "no mapping on registration" principle.
o Added placeholder notes about several tasks, notably reorganizing o Added placeholder notes about several tasks, notably reorganizing
Section 4 and Section 5 so that subsection numbers are parallel. 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" 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 in the lookup phase that was spotted by Mark Davis. Inserted a
note there about alternate ways to deal with the resulting note there about alternate ways to deal with the resulting
terminology problem. terminology problem.
o Added a temporarily appendix (above) to document alternate o Added a temporarily appendix (above) to document alternate
strategies for possible replacements for Section 5.3. strategies for possible replacements for former section 5.3 (see
Appendix B.14.
C.11. Version -11 B.11. Version -11
o Removed dangling reference to "C-label" (editing error in prior o Removed dangling reference to "C-label" (editing error in prior
draft). draft).
o Recast the last steps of the Lookup description to eliminate o Recast the last steps of the Lookup description to eliminate
"apparent" (previously "putative") terminology. "apparent" (previously "putative") terminology.
o Rewrote major portions of the temporary appendix that describes o Rewrote major portions of the temporary appendix that describes
transitional mappings to improve clarity and add context. transitional mappings to improve clarity and add context.
o Did some fine-tuning of terminology, notably in Section 3.2.1. o Did some fine-tuning of terminology, notably in Section 3.2.1.
C.12. Version -12 B.12. Version -12
o Extensive editorial improvements, mostly due to suggestions from o Extensive editorial improvements, mostly due to suggestions from
Lisa Dusseault. Lisa Dusseault.
o Conformance statements have been made consistent, especially in o Conformance statements have been made consistent, especially in
Section 4.2.1 and subsequent text, which said "SHOULD" in one Section 4.2.1 and subsequent text, which said "SHOULD" in one
place and then said "MAY" as the result of incomplete removal of place and then said "MAY" as the result of incomplete removal of
registration-time mapping. Also clarified the definition of registration-time mapping. Also clarified the definition of
"registration processes" in Section 4.1 -- the previous text had "registration processes" in Section 4.1 -- the previous text had
confused several people. confused several people.
skipping to change at page 25, line 45 skipping to change at page 21, line 41
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 B.13. Version -13
o Modified the "putative label" text to better explain the term and o Modified the "putative label" text to better explain the term and
explicitly point back to Defs. explicitly point back to Defs.
o Slight rewrite of Section 5.3 to clarify the NFC requirement and o Slight rewrite of former section 5.3 to clarify the NFC
to start the transition toward having some of the explanation in requirement and to start the transition toward having some of the
the Mapping document. The latter might need to be undone as WG explanation in the Mapping document. That whole section has been
consensus evolves. removed in -14, see Appendix B.14 for more information.
B.14. Version -14
o Fixed substantive typographical error caught by Wil Tan.
o Added a check for consecutive hyphens in positions 3 and 4 to
Lookup.
o Reflected several changes suggested by Andrew Sullivan.
o Rearranged and rewrote material to reflect the mapping document
and its status.
o The former Section 5.3 and Appendix A, which discussed mapping
alternatives, have been dropped entirely. Such discussion now
belongs in the Mapping document, the portion of Rationale that
supports it, or not at all. Section 5.2 has been rewritten
slightly to point to Mapping for those issues.
o Note: With the revised mapping material inserted, I've just about
given up on the idea of having the subsections of Sections 4 and 5
exactly parallel each other. Anyone who still feels strongly
about this should be prepared to make very specific suggestions.
--JcK
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. 49 change blocks. 
318 lines changed or deleted 143 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/