idnits 2.17.00 (12 Aug 2021)
/tmp/idnits15887/draft-ietf-idnabis-rationale-11.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** The document seems to lack a License Notice according IETF Trust
Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009
Section 6.b -- however, there's a paragraph with a matching beginning.
Boilerplate error?
(You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Feb 2009 rather than one of the newer Notices. See
https://trustee.ietf.org/license-info/.)
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 80: '... CONTEXTUAL RULE REQUIRED . . . . . . ...'
RFC 2119 keyword, line 459: '... CONTEXTUAL RULE REQUIRED, DISALLOWED ...'
RFC 2119 keyword, line 485: '...3.1.2. CONTEXTUAL RULE REQUIRED...'
RFC 2119 keyword, line 1539: '...nd CONTEXTUAL RULE REQUIRED categories...'
RFC 2119 keyword, line 1668: '...esented directly in ASCII MUST use the...'
(2 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document seems to contain a disclaimer for pre-RFC5378 work, and may
have content which was first submitted before 10 November 2008. The
disclaimer is necessary when there are original authors that you have
been unable to contact, or if some do not wish to grant the BCP78 rights
to the IETF Trust. If you are able to get all authors (current and
original) to grant those rights, you can and should remove the
disclaimer; otherwise, the disclaimer is needed and you can ignore this
comment. (See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (August 13, 2009) is 4663 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'ASCII' is defined on line 1820, but no explicit
reference was found in the text
== Unused Reference: 'Unicode-UAX15' is defined on line 1861, but no
explicit reference was found in the text
== Unused Reference: 'BIG5' is defined on line 1877, but no explicit
reference was found in the text
== Unused Reference: 'GB18030' is defined on line 1886, but no explicit
reference was found in the text
== Unused Reference: 'RFC0810' is defined on line 1896, but no explicit
reference was found in the text
== Unused Reference: 'RFC2673' is defined on line 1927, but no explicit
reference was found in the text
== Unused Reference: 'RFC4690' is defined on line 1957, but no explicit
reference was found in the text
== Unused Reference: 'Unicode-UTR36' is defined on line 1975, but no
explicit reference was found in the text
== Outdated reference: draft-ietf-idnabis-defs has been published as RFC
5890
== Outdated reference: draft-ietf-idnabis-tables has been published as RFC
5892
** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891)
-- No information found for draft-ietf-idnabis-mapping - is the name
correct?
-- Obsolete informational reference (is this intentional?): RFC 810
(Obsoleted by RFC 952)
-- Obsolete informational reference (is this intentional?): RFC 2535
(Obsoleted by RFC 4033, RFC 4034, RFC 4035)
-- Obsolete informational reference (is this intentional?): RFC 2671
(Obsoleted by RFC 6891)
-- Obsolete informational reference (is this intentional?): RFC 2673
(Obsoleted by RFC 6891)
-- Obsolete informational reference (is this intentional?): RFC 3454
(Obsoleted by RFC 7564)
-- Obsolete informational reference (is this intentional?): RFC 3491
(Obsoleted by RFC 5891)
Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 9 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. Klensin
3 Internet-Draft August 13, 2009
4 Intended status: Informational
5 Expires: February 14, 2010
7 Internationalized Domain Names for Applications (IDNA): Background,
8 Explanation, and Rationale
9 draft-ietf-idnabis-rationale-11.txt
11 Status of this Memo
13 This Internet-Draft is submitted to IETF in full conformance with the
14 provisions of BCP 78 and BCP 79. This document may contain material
15 from IETF Documents or IETF Contributions published or made publicly
16 available before November 10, 2008. The person(s) controlling the
17 copyright in some of this material may not have granted the IETF
18 Trust the right to allow modifications of such material outside the
19 IETF Standards Process. Without obtaining an adequate license from
20 the person(s) controlling the copyright in such materials, this
21 document may not be modified outside the IETF Standards Process, and
22 derivative works of it may not be created outside the IETF Standards
23 Process, except to format it for publication as an RFC or to
24 translate it into languages other than English.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF), its areas, and its working groups. Note that
28 other groups may also distribute working documents as Internet-
29 Drafts.
31 Internet-Drafts are draft documents valid for a maximum of six months
32 and may be updated, replaced, or obsoleted by other documents at any
33 time. It is inappropriate to use Internet-Drafts as reference
34 material or to cite them other than as "work in progress."
36 The list of current Internet-Drafts can be accessed at
37 http://www.ietf.org/ietf/1id-abstracts.txt.
39 The list of Internet-Draft Shadow Directories can be accessed at
40 http://www.ietf.org/shadow.html.
42 This Internet-Draft will expire on February 14, 2010.
44 Copyright Notice
46 Copyright (c) 2009 IETF Trust and the persons identified as the
47 document authors. All rights reserved.
49 This document is subject to BCP 78 and the IETF Trust's Legal
50 Provisions Relating to IETF Documents in effect on the date of
51 publication of this document (http://trustee.ietf.org/license-info).
52 Please review these documents carefully, as they describe your rights
53 and restrictions with respect to this document.
55 Abstract
57 Several years have passed since the original protocol for
58 Internationalized Domain Names (IDNs) was completed and deployed.
59 During that time, a number of issues have arisen, including the need
60 to update the system to deal with newer versions of Unicode. Some of
61 these issues require tuning of the existing protocols and the tables
62 on which they depend. This document provides an overview of a
63 revised system and provides explanatory material for its components.
65 Table of Contents
67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
68 1.1. Context and Overview . . . . . . . . . . . . . . . . . . . 4
69 1.2. Discussion Forum . . . . . . . . . . . . . . . . . . . . . 5
70 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
71 1.3.1. DNS "Name" Terminology . . . . . . . . . . . . . . . . 5
72 1.3.2. New Terminology and Restrictions . . . . . . . . . . . 6
73 1.4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 6
74 1.5. Applicability and Function of IDNA . . . . . . . . . . . . 7
75 1.6. Comprehensibility of IDNA Mechanisms and Processing . . . 8
76 2. Processing in IDNA2008 . . . . . . . . . . . . . . . . . . . . 9
77 3. Permitted Characters: An Inclusion List . . . . . . . . . . . 9
78 3.1. A Tiered Model of Permitted Characters and Labels . . . . 10
79 3.1.1. PROTOCOL-VALID . . . . . . . . . . . . . . . . . . . . 10
80 3.1.2. CONTEXTUAL RULE REQUIRED . . . . . . . . . . . . . . . 11
81 3.1.2.2. Rules and Their Application . . . . . . . . . . . 12
82 3.1.3. DISALLOWED . . . . . . . . . . . . . . . . . . . . . . 12
83 3.1.4. UNASSIGNED . . . . . . . . . . . . . . . . . . . . . . 13
84 3.2. Registration Policy . . . . . . . . . . . . . . . . . . . 14
85 3.3. Layered Restrictions: Tables, Context, Registration,
86 Applications . . . . . . . . . . . . . . . . . . . . . . . 14
87 4. Issues that Constrain Possible Solutions . . . . . . . . . . . 15
88 4.1. Display and Network Order . . . . . . . . . . . . . . . . 15
89 4.2. Entry and Display in Applications . . . . . . . . . . . . 16
90 4.3. Linguistic Expectations: Ligatures, Digraphs, and
91 Alternate Character Forms . . . . . . . . . . . . . . . . 18
92 4.4. Case Mapping and Related Issues . . . . . . . . . . . . . 20
93 4.5. Right to Left Text . . . . . . . . . . . . . . . . . . . . 21
94 5. IDNs and the Robustness Principle . . . . . . . . . . . . . . 21
95 6. Front-end and User Interface Processing for Lookup . . . . . . 22
96 7. Migration from IDNA2003 and Unicode Version Synchronization . 24
97 7.1. Design Criteria . . . . . . . . . . . . . . . . . . . . . 24
98 7.1.1. Summary and Discussion of IDNA Validity Criteria . . . 25
99 7.1.2. Labels in Registration . . . . . . . . . . . . . . . . 25
100 7.1.3. Labels in Lookup . . . . . . . . . . . . . . . . . . . 26
101 7.2. Changes in Character Interpretations . . . . . . . . . . . 27
102 7.3. Character Mapping . . . . . . . . . . . . . . . . . . . . 29
103 7.4. The Question of Prefix Changes . . . . . . . . . . . . . . 29
104 7.4.1. Conditions Requiring a Prefix Change . . . . . . . . . 29
105 7.4.2. Conditions Not Requiring a Prefix Change . . . . . . . 30
106 7.4.3. Implications of Prefix Changes . . . . . . . . . . . . 30
107 7.5. Stringprep Changes and Compatibility . . . . . . . . . . . 31
108 7.6. The Symbol Question . . . . . . . . . . . . . . . . . . . 31
109 7.7. Migration Between Unicode Versions: Unassigned Code
110 Points . . . . . . . . . . . . . . . . . . . . . . . . . . 33
111 7.8. Other Compatibility Issues . . . . . . . . . . . . . . . . 34
112 8. Name Server Considerations . . . . . . . . . . . . . . . . . . 35
113 8.1. Processing Non-ASCII Strings . . . . . . . . . . . . . . . 35
114 8.2. DNSSEC Authentication of IDN Domain Names . . . . . . . . 35
115 8.3. Root and other DNS Server Considerations . . . . . . . . . 36
116 9. Internationalization Considerations . . . . . . . . . . . . . 36
117 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
118 10.1. IDNA Character Registry . . . . . . . . . . . . . . . . . 37
119 10.2. IDNA Context Registry . . . . . . . . . . . . . . . . . . 37
120 10.3. IANA Repository of IDN Practices of TLDs . . . . . . . . . 37
121 11. Security Considerations . . . . . . . . . . . . . . . . . . . 37
122 11.1. General Security Issues with IDNA . . . . . . . . . . . . 37
123 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38
124 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 38
125 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
126 14.1. Normative References . . . . . . . . . . . . . . . . . . . 39
127 14.2. Informative References . . . . . . . . . . . . . . . . . . 40
128 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 42
129 A.1. Changes between Version -00 and Version -01 of
130 draft-ietf-idnabis-rationale . . . . . . . . . . . . . . . 42
131 A.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 43
132 A.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 43
133 A.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 44
134 A.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 44
135 A.6. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 44
136 A.7. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 45
137 A.8. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 45
138 A.9. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 45
139 A.10. Version -10 . . . . . . . . . . . . . . . . . . . . . . . 46
140 A.11. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 46
141 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47
143 1. Introduction
145 1.1. Context and Overview
147 Internationalized Domain Names in Applications (IDNA) is a collection
148 of standards that allow client applications to convert some Unicode
149 mnemonics to an ASCII-compatible encoding form ("ACE") which is a
150 valid DNS label containing only letters, digits, and hyphens. The
151 specific form of ACE label used by IDNA is called an "A-label". A
152 client can look up an exact A-label in the existing DNS, so A-labels
153 do not require any extensions to DNS, upgrades of DNS servers or
154 updates to low-level client libraries. An A-label is recognizable
155 from the prefix "xn--" before the characters produced by the Punycode
156 algorithm [RFC3492], thus a user application can identify an A-label
157 and convert it into Unicode (or some local coded character set) for
158 display.
160 On the registry side, IDNA allows a registry to offer
161 Internationalized Domain Names (IDNs) for registration as A-labels.
162 A registry may offer any subset of valid IDNs, and may apply any
163 restrictions or bundling (grouping of similar labels together in one
164 registration) appropriate for the context of that registry.
165 Registration of labels is sometimes discussed separately from lookup,
166 and is subject to a few specific requirements that do not apply to
167 lookup.
169 DNS clients and registries are subject to some differences in
170 requirements for handling IDNs. In particular, registries are urged
171 to register only exact, valid A-labels, while clients might do some
172 mapping to get from otherwise-invalid user input to a valid A-label.
174 The first version of IDNA was published in 2003 and is referred to
175 here as IDNA2003 to contrast it with the current version, which is
176 known as IDNA2008 (after the year in which IETF work started on it).
177 IDNA2003 consists of four documents: the IDNA base specification
178 [RFC3490], Nameprep [RFC3491], Punycode [RFC3492], and Stringprep
179 [RFC3454]. The current set of documents, IDNA2008, are not dependent
180 on any of the IDNA2003 specifications other than the one for Punycode
181 encoding. References to "these specifications" or "these documents"
182 are to the entire IDNA2008 set listed in [IDNA2008-Defs]. The
183 characters that are valid in A-labels are identified from rules
184 listed in the Tables document [IDNA2008-Tables], but validity can be
185 derived from the Unicode properties of those characters with a very
186 few exceptions.
188 Traditionally, DNS labels are matched case-insensitively
189 [RFC1034][RFC1035]. That convention was preserved in IDNA2003 by a
190 case-folding operation that generally maps capital letters into
191 lower-case ones. However, if case rules are enforced from one
192 language, another language sometimes loses the ability to treat two
193 characters separately. Case-sensitivity is treated slightly
194 differently in IDNA2008.
196 IDNA2003 used Unicode version 3.2 only. In order to keep up with new
197 characters added in new versions of UNICODE, IDNA2008 decouples its
198 rules from any particular version of UNICODE. Instead, the
199 attributes of new characters in Unicode, supplemented by a small
200 number of exception cases, determine how and whether the characters
201 can be used in IDNA labels.
203 This document provides informational context for IDNA2008, including
204 terminology, background, and policy discussions.
206 1.2. Discussion Forum
208 [[ RFC Editor: please remove this section. ]]
210 IDNA2008 is being discussed in the IETF "idnabis" Working Group and
211 on the mailing list idna-update@alvestrand.no
213 1.3. Terminology
215 Terminology for IDNA2008 appears in [IDNA2008-Defs]. That document
216 also contains a roadmap to the IDNA2008 document collection. No
217 attempt should be made to understand this document without the
218 definitions and concepts that appear there.
220 1.3.1. DNS "Name" Terminology
222 In the context of IDNs, the DNS term "name" has introduced some
223 confusion as people speak of DNS labels in terms of the words or
224 phrases of various natural languages. Historically, many of the
225 "names" in the DNS have been mnemonics to identify some particular
226 concept, object, or organization. They are typically rooted in some
227 language because most people think in language-based ways. But,
228 because they are mnemonics, they need not obey the orthographic
229 conventions of any language: it is not a requirement that it be
230 possible for them to be "words".
232 This distinction is important because the reasonable goal of an IDN
233 effort is not to be able to write the great Klingon (or language of
234 one's choice) novel in DNS labels but to be able to form a usefully
235 broad range of mnemonics in ways that are as natural as possible in a
236 very broad range of scripts.
238 1.3.2. New Terminology and Restrictions
240 These documents introduce new terminology, and precise definitions
241 (in [IDNA2008-Defs]), for the terms "U-label", "A-Label", LDH-label
242 (to which all valid pre-IDNA host names conformed), Reserved-LDH-
243 label (R-LDH-label), XN-label, Fake-A-Label, and Non-Reserved-LDH-
244 label (NR-LDH-label).
246 In addition, the term "putative label" has been adopted to refer to a
247 label that may appear to meet certain definitional constraints but
248 has not yet been sufficiently tested for validity.
250 These definitions are also illustrated in Figure 1 of the Definitions
251 Document [IDNA2008-Defs]. R-LDH-labels contain "--" in the third and
252 fourth character from the beginning of the label. In IDNA-aware
253 applications, only a subset of these reserved labels is permitted to
254 be used, namely the A-label subset. A-labels are a subset of the
255 R-LDH-labels that begin with the case-insensitive string "xn--".
256 Labels that bear this prefix but which are not otherwise valid fall
257 into the "Fake-A-label" category. The non-reserved labels (NR-LDH-
258 labels) are implicitly valid since they do not trigger any
259 resemblance to IDNA-landr NR-LDH-labels.
261 The creation of the Reserved-LDH category is required for three
262 reasons:
264 o to prevent confusion with pre-IDNA coding forms;
266 o to permit future extensions that would require changing the
267 prefix, no matter how unlikely those might be (see Section 7.4);
268 and
270 o to reduce the opportunities for attacks via the Punycode encoding
271 algorithm itself.
273 As with other documents in the IDNA2008 set, this document uses the
274 term "registry" to describe any zone in the DNS. That term, and the
275 terms "zone" or "zone administration", are interchangeable.
277 1.4. Objectives
279 These are the main objectives in revising IDNA.
281 o Use a more recent version of Unicode, and allow IDNA to be
282 independent of Unicode versions, so that IDNA2008 need not be
283 updated for implementations to adopt codepoints from new Unicode
284 versions.
286 o Fix a very small number of code-point categorizations that have
287 turned out to cause problems in the communities that use those
288 code-points.
290 o Reduce the dependency on mapping, in order that the pre-mapped
291 forms (which are not valid IDNA labels) tend to appear less often
292 in various contexts, in favor of valid A-labels.
294 o Fix some details in the bidirectional codepoint handling
295 algorithms.
297 1.5. Applicability and Function of IDNA
299 The IDNA specification solves the problem of extending the repertoire
300 of characters that can be used in domain names to include a large
301 subset of the Unicode repertoire.
303 IDNA does not extend DNS. Instead, the applications (and, by
304 implication, the users) continue to see an exact-match lookup
305 service. Either there is a single exactly-matching (subject to the
306 base DNS requirement of case-insensitive ASCII matching) name or
307 there is no match. This model has served the existing applications
308 well, but it requires, with or without internationalized domain
309 names, that users know the exact spelling of the domain names that
310 are to be typed into applications such as web browsers and mail user
311 agents. The introduction of the larger repertoire of characters
312 potentially makes the set of misspellings larger, especially given
313 that in some cases the same appearance, for example on a business
314 card, might visually match several Unicode code points or several
315 sequences of code points.
317 The IDNA standard does not require any applications to conform to it,
318 nor does it retroactively change those applications. An application
319 can elect to use IDNA in order to support IDN while maintaining
320 interoperability with existing infrastructure. If an application
321 wants to use non-ASCII characters in public DNS domain names, IDNA is
322 the only currently-defined option. Adding IDNA support to an
323 existing application entails changes to the application only, and
324 leaves room for flexibility in front-end processing and more
325 specifically in the user interface (see Section 6).
327 A great deal of the discussion of IDN solutions has focused on
328 transition issues and how IDNs will work in a world where not all of
329 the components have been updated. Proposals that were not chosen by
330 the original IDN Working Group would have depended on updating of
331 user applications, DNS resolvers, and DNS servers in order for a user
332 to apply an internationalized domain name in any form or coding
333 acceptable under that method. While processing must be performed
334 prior to or after access to the DNS, IDNA requires no changes to the
335 DNS protocol or any DNS servers or the resolvers on user's computers.
337 IDNA allows the graceful introduction of IDNs not only by avoiding
338 upgrades to existing infrastructure (such as DNS servers and mail
339 transport agents), but also by allowing some limited use of IDNs in
340 applications by using the ASCII-encoded representation of the labels
341 containing non-ASCII characters. While such names are user-
342 unfriendly to read and type, and hence not optimal for user input,
343 they can be used as a last resort to allow rudimentary IDN usage.
344 For example, they might be the best choice for display if it were
345 known that relevant fonts were not available on the user's computer.
346 In order to allow user-friendly input and output of the IDNs and
347 acceptance of some characters as equivalent to those to be processed
348 according to the protocol, the applications need to be modified to
349 conform to this specification.
351 This version of IDNA uses the Unicode character repertoire, for
352 continuity with the original version of IDNA.
354 1.6. Comprehensibility of IDNA Mechanisms and Processing
356 One goal of IDNA2008, which is aided by the main goal of reducing the
357 dependency on mapping, is to improve the general understanding of how
358 IDNA works and what characters are permitted and what happens to
359 them. Comprehensibility and predictability to users and registrants
360 are important design goals for this effort. End-user applications
361 have an important role to play in increasing this comprehensibility.
363 Any system that tries to handle international characters encounters
364 some common problems. For example, a UI cannot display a character
365 if no font for that character is available. In some cases,
366 internationalization enables effective localization while maintaining
367 some global uniformity but losing some universality.
369 It is difficult to even make suggestions for end-user applications to
370 cope when characters and fonts are not available. Because display
371 functions are rarely controlled by the types of applications that
372 would call upon IDNA, such suggestions will rarely be very effective.
374 Converting between local character sets and normalized Unicode, if
375 needed, is part of this set of user agent issues. This conversion
376 introduces complexity in a system that is not Unicode-native. If a
377 label is converted to a local character set that does not have all
378 the needed characters, or that uses different character-coding
379 principles, the user agent may have to add special logic to avoid or
380 reduce loss of information.
382 The major difficulty may lie in accurately identifying the incoming
383 character set and applying the correct conversion routine. Even more
384 difficult, the local character coding system could be based on
385 conceptually different assumptions than those used by Unicode (e.g.,
386 choice of font encodings used for publications in some Indic
387 scripts). Those differences may not easily yield unambiguous
388 conversions or interpretations even if each coding system is
389 internally consistent and adequate to represent the local language
390 and script.
392 IDNA2008 shifts responsibility for character mapping and other
393 adjustments from the protocol (where it was located in IDNA2003) to
394 pre-processing before invoking IDNA itself. The intent is that this
395 change will lead to greater usage of fully-valid A-Labels or U-labels
396 in display, transit and storage, which should aid comprehensibility
397 and predictability. A careful look at pre-processing raises issues
398 about what that pre-processing should do and at what point pre-
399 processing becomes harmful, how universally consistent pre-processing
400 algorithms can be, and how to be compatible with labels prepared in a
401 IDNA2003 context. Those issues are discussed in Section 6 and in the
402 separate document [IDNA2008-Mapping].
404 2. Processing in IDNA2008
406 These specifications separate Domain Name Registration and Lookup in
407 the protocol specification. Although most steps in the two processes
408 are similar, the separation reflects current practice in which per-
409 registry (DNS zone) restrictions and special processing are applied
410 at registration time but not during lookup. Another significant
411 benefit is that separation facilitates incremental addition of
412 permitted character groups to avoid freezing on one particular
413 version of Unicode.
415 The actual registration and lookup protocols for IDNA2008 are
416 specified in [IDNA2008-Protocol].
418 3. Permitted Characters: An Inclusion List
420 IDNA2008 adopts the inclusion model. A code-point is assumed to be
421 invalid for IDN use unless it is included as part of a Unicode
422 property-based rule or, in rare cases, included individually by an
423 exception. When an implementation moves to a new version of Unicode,
424 the rules may indicate new valid code-points.
426 This section provides an overview of the model used to establish the
427 algorithm and character lists of [IDNA2008-Tables] and describes the
428 names and applicability of the categories used there. Note that the
429 inclusion of a character in the first category group (Section 3.1.1)
430 does not imply that it can be used indiscriminately; some characters
431 are associated with contextual rules that must be applied as well.
433 The information given in this section is provided to make the rules,
434 tables, and protocol easier to understand. The normative generating
435 rules that correspond to this informal discussion appear in
436 [IDNA2008-Tables] and the rules that actually determine what labels
437 can be registered or looked up are in [IDNA2008-Protocol].
439 3.1. A Tiered Model of Permitted Characters and Labels
441 Moving to an inclusion model involves a new specification for the
442 list of characters that are permitted in IDNs. In IDNA2003,
443 character validity is independent of context and fixed forever (or
444 until the standard is replaced). However, globally context-
445 independent rules have proved to be impractical because some
446 characters, especially those that are called "Join_Controls" in
447 Unicode, are needed to make reasonable use of some scripts but have
448 no visible effect in others. IDNA2003 prohibited those types of
449 characters entirely by discarding them. We now have a consensus that
450 under some conditions, these "joiner" characters are legitimately
451 needed to allow useful mnemonics for some languages and scripts. In
452 general, context-dependent rules help deal with characters (generally
453 characters that would otherwise be prohibited entirely) that are used
454 differently or perceived differently across different scripts, and
455 allow the standard to be applied more appropriately in cases where a
456 string is not universally handled the same way.
458 IDNA2008 divides all possible Unicode code-points into four
459 categories: PROTOCOL-VALID, CONTEXTUAL RULE REQUIRED, DISALLOWED and
460 UNASSIGNED.
462 3.1.1. PROTOCOL-VALID
464 Characters identified as "PROTOCOL-VALID" (often abbreviated
465 "PVALID") are permitted in IDNs. Their use may be restricted by
466 rules about the context in which they appear or by other rules that
467 apply to the entire label in which they are to be embedded. For
468 example, any label that contains a character in this category that
469 has a "right-to-left" property must be used in context with the
470 "Bidi" rules (see [IDNA2008-Bidi]).
472 The term "PROTOCOL-VALID" is used to stress the fact that the
473 presence of a character in this category does not imply that a given
474 registry need accept registrations containing any of the characters
475 in the category. Registries are still expected to apply judgment
476 about labels they will accept and to maintain rules consistent with
477 those judgments (see [IDNA2008-Protocol] and Section 3.3).
479 Characters that are placed in the "PROTOCOL-VALID" category are
480 expected to never be removed from it or reclassified. While
481 theoretically characters could be removed from Unicode, such removal
482 would be inconsistent with the Unicode stability principles (see
483 [Unicode51], Appendix F) and hence should never occur.
485 3.1.2. CONTEXTUAL RULE REQUIRED
487 Some characters may be unsuitable for general use in IDNs but
488 necessary for the plausible support of some scripts. The two most
489 commonly-cited examples are the zero-width joiner and non-joiner
490 characters (ZWJ, U+200D and ZWNJ, U+200C) but other characters may
491 require special treatment because they would otherwise be DISALLOWED
492 (typically because Unicode considers them punctuation or special
493 symbols) but need to be permitted in limited contexts. Other
494 characters are given this special treatment because they pose
495 exceptional danger of being used to produce misleading labels or to
496 cause unacceptable ambiguity in label matching and interpretation.
498 3.1.2.1. Contextual Restrictions
500 Characters with contextual restrictions are identified as "CONTEXTUAL
501 RULE REQUIRED" and associated with a rule. The rule defines whether
502 the character is valid in a particular string, and also whether the
503 rule itself is to be applied on lookup as well as registration.
505 A distinction is made between characters that indicate or prohibit
506 joining and ones similar to them (known as "CONTEXT-JOINER" or
507 "CONTEXTJ") and other characters requiring contextual treatment
508 ("CONTEXT-OTHER" or "CONTEXTO"). Only the former require full
509 testing at lookup time.
511 It is important to note that these contextual rules cannot prevent
512 all uses of the relevant characters that might be confusing or
513 problematic. What they are expected do is to confine applicability
514 of the characters to scripts (and narrower contexts) where zone
515 administrators are knowledgeable enough about the use of those
516 characters to be prepared to deal with them appropriately. For
517 example, a registry dealing with an Indic script that requires ZWJ
518 and/or ZWNJ as part of the writing system is expected to understand
519 where the characters have visible effect and where they do not and to
520 make registration rules accordingly. By contrast, a registry dealing
521 primarily with Latin or Cyrillic script might not be actively aware
522 that the characters exist, much less about the consequences of
523 embedding them in labels drawn from those scripts.
525 3.1.2.2. Rules and Their Application
527 Rules have descriptions such as "Must follow a character from Script
528 XYZ", "Must occur only if the entire label is in Script ABC", or
529 "Must occur only if the previous and subsequent characters have the
530 DFG property". The actual rules may be DEFINED or NULL. If present,
531 they may have values of "True" (character may be used in any position
532 in any label), "False" (character may not be used in any label), or
533 may be a set of procedural rules that specify the context in which
534 the character is permitted.
536 Examples of descriptions of typical rules, stated informally and in
537 English, include "Must follow a character from Script XYZ", "Must
538 occur only if the entire label is in Script ABC", "Must occur only if
539 the previous and subsequent characters have the DFG property".
541 Because it is easier to identify these characters than to know that
542 they are actually needed in IDNs or how to establish exactly the
543 right rules for each one, a rule may have a null value in a given
544 version of the tables. Characters associated with null rules are not
545 permitted to appear in putative labels for either registration or
546 lookup. Of course, a later version of the tables might contain a
547 non-null rule.
549 The actual rules and their descriptions are in [IDNA2008-Tables].
550 [[anchor9: ??? Section number would be good here.]] That document
551 also specifies the creation of a registry for future rules.
553 3.1.3. DISALLOWED
555 Some characters are inappropriate for use in IDNs and are thus
556 excluded for both registration and lookup (i.e., IDNA-conforming
557 applications performing name lookup should verify that these
558 characters are absent; if they are present, the label strings should
559 be rejected rather than converted to A-labels and looked up. Some of
560 these characters are problematic for use in IDNs (such as the
561 FRACTION SLASH character, U+2044), while some of them (such as the
562 various HEART symbols, e.g., U+2665, U+2661, and U+2765, see
563 Section 7.6) simply fall outside the conventions for typical
564 identifiers (basically letters and numbers).
566 Of course, this category would include code points that had been
567 removed entirely from Unicode should such removals ever occur.
569 Characters that are placed in the "DISALLOWED" category are expected
570 to never be removed from it or reclassified. If a character is
571 classified as "DISALLOWED" in error and the error is sufficiently
572 problematic, the only recourse would be either to introduce a new
573 code point into Unicode and classify it as "PROTOCOL-VALID" or for
574 the IETF to accept the considerable costs of an incompatible change
575 and replace the relevant RFC with one containing appropriate
576 exceptions.
578 There is provision for exception cases but, in general, characters
579 are placed into "DISALLOWED" if they fall into one or more of the
580 following groups:
582 o The character is a compatibility equivalent for another character.
583 In slightly more precise Unicode terms, application of
584 normalization method NFKC to the character yields some other
585 character.
587 o The character is an upper-case form or some other form that is
588 mapped to another character by Unicode casefolding.
590 o The character is a symbol or punctuation form or, more generally,
591 something that is not a letter, digit, or a mark that is used to
592 form a letter or digit.
594 3.1.4. UNASSIGNED
596 For convenience in processing and table-building, code points that do
597 not have assigned values in a given version of Unicode are treated as
598 belonging to a special UNASSIGNED category. Such code points are
599 prohibited in labels to be registered or looked up. The category
600 differs from DISALLOWED in that code points are moved out of it by
601 the simple expedient of being assigned in a later version of Unicode
602 (at which point, they are classified into one of the other categories
603 as appropriate).
605 The rationale for restricting the processing of UNASSIGNED characters
606 is simply that the properties of such code points cannot be
607 completely known until actual characters are assigned to them. If,
608 for example, such a code point was permitted to be included in a
609 label to be looked up, and the code point was later to be assigned to
610 a character that required some set of contextual rules, un-updated
611 instances of IDNA-aware software might permit lookup of labels
612 containing the previously-unassigned characters while updated
613 versions of IDNA-aware software might restrict their use in lookup,
614 depending on the contextual rules. It should be clear that under no
615 circumstance should an UNASSIGNED character be permitted in a label
616 to be registered as part of a domain name.
618 3.2. Registration Policy
620 While these recommendations cannot and should not define registry
621 policies, registries should develop and apply additional restrictions
622 as needed to reduce confusion and other problems. For example, it is
623 generally believed that labels containing characters from more than
624 one script are a bad practice although there may be some important
625 exceptions to that principle. Some registries may choose to restrict
626 registrations to characters drawn from a very small number of
627 scripts. For many scripts, the use of variant techniques such as
628 those as described in RFC 3843 [RFC3743] and RFC 4290 [RFC4290], and
629 illustrated for Chinese by the tables described in RFC 4713 [RFC4713]
630 may be helpful in reducing problems that might be perceived by users.
632 In general, users will benefit if registries only permit characters
633 from scripts that are well-understood by the registry or its
634 advisers. If a registry decides to reduce opportunities for
635 confusion by constructing policies that disallow characters used in
636 historic writing systems or characters whose use is restricted to
637 specialized, highly technical contexts, some relevant information may
638 be found in Section 2.4 "Specific Character Adjustments", Table 4
639 "Candidate Characters for Exclusion from Identifiers" of
640 [Unicode-UAX31] and Section 3.1. "General Security Profile for
641 Identifiers" in [Unicode-Security].
643 The requirement (in [IDNA2008-Protocol] [[anchor10: ?? Section
644 number]]) that registration procedures use only U-labels and/or
645 A-labels is intended to ensure that registrants are fully aware of
646 exactly what is being registered as well as encouraging use of those
647 canonical forms. That provision should not be interpreted as
648 requiring that registrant need to provide characters in a particular
649 code sequence. Registrant input conventions and management are part
650 of registrant-registrar interactions and relationships between
651 registries and registrars and are outside the scope of these
652 standards.
654 It is worth stressing that these principles of policy development and
655 application apply at all levels of the DNS, not only, e.g., TLD or
656 SLD registrations and that even a trivial, "anything permitted that
657 is valid under the protocol" policy is helpful in that it helps users
658 and application developers know what to expect.
660 3.3. Layered Restrictions: Tables, Context, Registration, Applications
662 The character rules in IDNA2008 are based on the realization that
663 there is no single magic bullet for any of the security,
664 confusability, or other issues associated with IDNs. Instead, the
665 specifications define a variety of approaches. The character tables
666 are the first mechanism, protocol rules about how those characters
667 are applied or restricted in context are the second, and those two in
668 combination constitute the limits of what can be done in the
669 protocol. As discussed in the previous section (Section 3.2),
670 registries are expected to restrict what they permit to be
671 registered, devising and using rules that are designed to optimize
672 the balance between confusion and risk on the one hand and maximum
673 expressiveness in mnemonics on the other.
675 In addition, there is an important role for user agents in warning
676 against label forms that appear problematic given their knowledge of
677 local contexts and conventions. Of course, no approach based on
678 naming or identifiers alone can protect against all threats.
680 4. Issues that Constrain Possible Solutions
682 4.1. Display and Network Order
684 Domain names are always transmitted in network order (the order in
685 which the code points are sent in protocols), but may have a
686 different display order (the order in which the code points are
687 displayed on a screen or paper). When a domain name contains
688 characters that are normally written right to left, display order may
689 be affected although network order is not. It gets even more
690 complicated if left to right and right to left labels are adjacent to
691 each other within a domain name. The decision about the display
692 order is ultimately under the control of user agents --including Web
693 browsers, mail clients, hosted Web applications and many more --
694 which may be highly localized. Should a domain name abc.def, in
695 which both labels are represented in scripts that are written right
696 to left, be displayed as fed.cba or cba.fed? Applications that are
697 in deployment today are already diverse, and one can find examples of
698 either choice.
700 The picture changes once again when an IDN appears in a
701 Internationalized Resource Identifier (IRI) [RFC3987]. An IRI or
702 Internationalized Email address contains elements other than the
703 domain name. For example, IRIs contain protocol identifiers and
704 field delimiter syntax such as "http://" or "mailto:" while email
705 addresses contain the "@" to separate local parts from domain names.
706 An IRI in network order begins with "http://" followed by domain
707 labels in network order, thus "http://abc.def".
709 User agents are not required to display and allow input of IRIs
710 directly but often do so. Implementors have to choose whether the
711 overall direction of these strings will always be left to right (or
712 right to left) for an IRI or email address. The natural order for a
713 user typing a domain name on a right to left system is fed.cba.
714 Should the R2L user agent reverse the entire domain name each time a
715 domain name is typed? Does this change if the user types "http://"
716 right before typing a domain name, thus implying that the user is
717 beginning at the beginning of the network order IRI? Experience in
718 the 1980s and 1990s with mixing systems in which domain name labels
719 were read in network order (left to right) and those in which those
720 labels were read right to left would predict a great deal of
721 confusion.
723 If each implementation of each application makes its own decisions on
724 these issues, users will develop heuristics that will sometimes fail
725 when switching applications. However, while some display order
726 conventions, voluntarily adopted, would be desirable to reduce
727 confusion, such suggestions are beyond the scope of these
728 specifications.
730 4.2. Entry and Display in Applications
732 Applications can accept and display domain names using any character
733 set or character coding system. The IDNA protocol does not
734 necessarily affect the interface between users and applications. An
735 IDNA-aware application can accept and display internationalized
736 domain names in two formats: the internationalized character set(s)
737 supported by the application (i.e., an appropriate local
738 representation of a U-label), and as an A-label. Applications may
739 allow the display of A-labels, but are encouraged to not do so except
740 as an interface for special purposes, possibly for debugging, or to
741 cope with display limitations. In general, they should allow, but
742 not encourage, user input of A-labels. A-labels are opaque, ugly,
743 and malicious variations on them are not easily detected by users.
744 Where possible, they should thus only be exposed when they are
745 absolutely needed. Because IDN labels can be rendered either as
746 A-labels or U-labels, the application may reasonably have an option
747 for the user to select the preferred method of display. Rendering
748 the U-label should normally be the default.
750 Domain names are often stored and transported in many places. For
751 example, they are part of documents such as mail messages and web
752 pages. They are transported in many parts of many protocols, such as
753 both the control commands of SMTP and associated message body parts,
754 and in the headers and the body content in HTTP. It is important to
755 remember that domain names appear both in domain name slots and in
756 the content that is passed over protocols.
758 In protocols and document formats that define how to handle
759 specification or negotiation of charsets, labels can be encoded in
760 any charset allowed by the protocol or document format. If a
761 protocol or document format only allows one charset, the labels must
762 be given in that charset. Of course, not all charsets can properly
763 represent all labels. If a U-label cannot be displayed in its
764 entirety, the only choice (without loss of information) may be to
765 display the A-label.
767 Where a protocol or document format allows IDNs, labels should be in
768 whatever character encoding and escape mechanism the protocol or
769 document format uses at that place. This provision is intended to
770 prevent situations in which, e.g., UTF-8 domain names appear embedded
771 in text that is otherwise in some other character coding.
773 All protocols that use domain name slots (See Section 2.3.1.6 in
774 [IDNA2008-Defs]) already have the capacity for handling domain names
775 in the ASCII charset. Thus, A-labels can inherently be handled by
776 those protocols.
778 These documents do not specify required mappings between one
779 character or code point and others. An extended discussion of
780 mapping issues occurs in Section 6 and specific recommendations
781 appear in [IDNA2008-Mapping]. In general, IDNA2008 prohibits
782 characters that would be mapped to others by normalization or other
783 rules. As examples, while mathematical characters based on Latin
784 ones are accepted as input to IDNA2003, they are prohibited in
785 IDNA2008. Similarly, upper-case characters, double-width characters,
786 and other variations are prohibited as IDNA input although mapping
787 them as needed in user interfaces is strongly encouraged.
789 Since the rules in [IDNA2008-Tables] have the effect that only
790 strings that are not transformed by NFKC are valid, if an application
791 chooses to perform NFKC normalization before lookup, that operation
792 is safe since this will never make the application unable to look up
793 any valid string. However, as discussed above, the application
794 cannot guarantee that any other application will perform that
795 mapping, so it should be used only with caution and for informed
796 users.
798 In many cases these prohibitions should have no effect on what the
799 user can type as input to the lookup process. It is perfectly
800 reasonable for systems that support user interfaces to perform some
801 character mapping that is appropriate to the local environment. This
802 would normally be done prior to actual invocation of IDNA. At least
803 conceptually, the mapping would be part of the Unicode conversions
804 discussed above and in [IDNA2008-Protocol]. However, those changes
805 will be local ones only -- local to environments in which users will
806 clearly understand that the character forms are equivalent. For use
807 in interchange among systems, it appears to be much more important
808 that U-labels and A-labels can be mapped back and forth without loss
809 of information.
811 One specific, and very important, instance of this strategy arises
812 with case-folding. In the ASCII-only DNS, names are looked up and
813 matched in a case-independent way, but no actual case-folding occurs.
814 Names can be placed in the DNS in either upper or lower case form (or
815 any mixture of them) and that form is preserved, returned in queries,
816 and so on. IDNA2003 approximated that behavior for non-ASCII strings
817 by performing case-folding at registration time (resulting in only
818 lower-case IDNs in the DNS) and when names were looked up.
820 As suggested earlier in this section, it appears to be desirable to
821 do as little character mapping as possible as long as Unicode works
822 correctly (e.g., NFC mapping to resolve different codings for the
823 same character is still necessary although the specifications require
824 that it be performed prior to invoking the protocol) in order to make
825 the mapping between A-labels and U-labels idempotent. Case-mapping
826 is not an exception to this principle. If only lower case characters
827 can be registered in the DNS (i.e., be present in a U-label), then
828 IDNA2008 should prohibit upper-case characters as input even though
829 user interfaces to applications should probably map those characters.
830 Some other considerations reinforce this conclusion. For example, in
831 ASCII case-mapping for individual characters, uppercase(character)
832 must be equal to uppercase(lowercase(character)). That may not be
833 true with IDNs. In some scripts that use case distinctions, there
834 are a few characters that do not have counterparts in one case or the
835 other. The relationship between upper case and lower case may even
836 be language-dependent, with different languages (or even the same
837 language in different areas) expecting different mappings. User
838 agents can meet the expectations of users who are accustomed to the
839 case-insensitive DNS environment by performing case folding prior to
840 IDNA processing, but the IDNA procedures themselves should neither
841 require such mapping nor expect them when they are not natural to the
842 localized environment.
844 4.3. Linguistic Expectations: Ligatures, Digraphs, and Alternate
845 Character Forms
847 Users have expectations about character matching or equivalence that
848 are based on their own languages and the orthography of those
849 languages. These expectations may not always be met in a global
850 system, especially if multiple languages are written using the same
851 script but using different conventions. Some examples:
853 o A Norwegian user might expect a label with the ae-ligature to be
854 treated as the same label as one using the Swedish spelling with
855 a-diaeresis even though applying that mapping to English would be
856 astonishing to users.
858 o A user in German might expect a label with an o-umlaut and a label
859 that had "oe" substituted, but was otherwise the same, treated as
860 equivalent even though that substitution would be a clear error in
861 Swedish.
863 o A Chinese user might expect automatic matching of Simplified and
864 Traditional Chinese characters, but applying that matching for
865 Korean or Japanese text would create considerable confusion.
867 o An English user might expect "theater" and "theatre" to match.
869 A number of languages use alphabetic scripts in which single phonemes
870 are written using two characters, termed a "digraph", for example,
871 the "ph" in "pharmacy" and "telephone". (Such characters can also
872 appear consecutively without forming a digraph, as in "tophat".)
873 Certain digraphs may be indicated typographically by setting the two
874 characters closer together than they would be if used consecutively
875 to represent different phonemes. Some digraphs are fully joined as
876 ligatures. For example, the word "encyclopaedia" is sometimes set
877 with a U+00E6 LATIN SMALL LIGATURE AE. When ligature and digraph
878 forms have the same interpretation across all languages that use a
879 given script, application of Unicode normalization generally resolves
880 the differences and causes them to match. When they have different
881 interpretations, matching must utilize other methods, presumably
882 chosen at the registry level, or users must be educated to understand
883 that matching will not occur.
885 The nature of the problem can be illustrated by many words in the
886 Norwegian language, where the "ae" ligature is the 27th letter of a
887 29-letter extended Latin alphabet. It is equivalent to the 28th
888 letter of the Swedish alphabet (also containing 29 letters), U+00E4
889 LATIN SMALL LETTER A WITH DIAERESIS, for which an "ae" cannot be
890 substituted according to current orthographic standards. That
891 character (U+00E4) is also part of the German alphabet where, unlike
892 in the Nordic languages, the two-character sequence "ae" is usually
893 treated as a fully acceptable alternate orthography for the "umlauted
894 a" character. The inverse is however not true, and those two
895 characters cannot necessarily be combined into an "umlauted a". This
896 also applies to another German character, the "umlauted o" (U+00F6
897 LATIN SMALL LETTER O WITH DIAERESIS) which, for example, cannot be
898 used for writing the name of the author "Goethe". It is also a
899 letter in the Swedish alphabet where, like the "a with diaeresis", it
900 cannot be correctly represented as "oe" and in the Norwegian
901 alphabet, where it is represented, not as "o with diaeresis", but as
902 "slashed o", U+00F8.
904 Some of the ligatures that have explicit code points in Unicode were
905 given special handling in IDNA2003 and now pose additional problems
906 in transition. See Section 7.2.
908 Additional cases with alphabets written right to left are described
909 in Section 4.5.
911 Matching and comparison algorithm selection often requires
912 information about the language being used, context, or both --
913 information that is not available to IDNA or the DNS. Consequently,
914 these specifications make no attempt to treat combined characters in
915 any special way. A registry that is aware of the language context in
916 which labels are to be registered, and where that language sometimes
917 (or always) treats the two- character sequences as equivalent to the
918 combined form, should give serious consideration to applying a
919 "variant" model [RFC3743][RFC4290], or to prohibiting registration of
920 one of the forms entirely, to reduce the opportunities for user
921 confusion and fraud that would result from the related strings being
922 registered to different parties.
924 4.4. Case Mapping and Related Issues
926 In the DNS, ASCII letters are stored with their case preserved.
927 Matching during the query process is case-independent, but none of
928 the information that might be represented by choices of case has been
929 lost. That model has been accidentally helpful because, as people
930 have created DNS labels by catenating words (or parts of words) to
931 form labels, case has often been used to distinguish among components
932 and make the labels more memorable.
934 Since DNS servers do not get involved in parsing IDNs, they cannot do
935 case-independent matching. Thus, keeping the cases separate in
936 lookup or registration, and doing matching at the server, is not
937 feasible with IDNA or any similar approach. Case-matching must be
938 done, if desired, by IDN clients even though it wasn't done by ASCII-
939 only DNS clients. That situation was recognized in IDNA2003 and
940 nothing in these specifications fundamentally changes it or could do
941 so. In IDNA2003, all characters are case-folded and mapped by
942 clients in a standardized step.
944 Some characters do not have upper case forms. For example the
945 Unicode case folding operation maps Greek Final Form Sigma (U+03C2)
946 to the medial form (U+03C3) and maps Eszett (German Sharp S, U+00DF)
947 to "ss". Neither of these mappings is reversible because the upper
948 case of U+03C3 is the Upper Case Sigma (U+03A3) and "ss" is an ASCII
949 string. IDNA2008 permits, at the risk of some incompatibility,
950 slightly more flexibility in this area by avoiding case folding and
951 treating these characters as themselves. Approaches to handling one-
952 way mappings are discussed in Section 7.2.
954 Because IDNA2003 maps Final Sigma and Eszett to other characters, and
955 the reverse mapping is never possible, that in some sense means that
956 neither Final Sigma nor Eszett can be represented in a IDNA2003 IDN.
957 With IDNA2008, both characters can be used in an IDN and so the
958 A-label used for lookup for any U-label containing those characters,
959 is now different. See Section 7.1 for a discussion of what kinds of
960 changes might require the IDNA prefix to change; after extended
961 discussions, the WG came to consensus that the change for these
962 characters did not justify a prefix change.
964 4.5. Right to Left Text
966 In order to be sure that the directionality of right to left text is
967 unambiguous, IDNA2003 required that any label in which right to left
968 characters appear both starts and ends with them and that it not
969 include any characters with strong left to right properties (that
970 excludes other alphabetic characters but permits European digits).
971 Any other string that contains a right to left character and does not
972 meet those requirements is rejected. This is one of the few places
973 where the IDNA algorithms (both in IDNA2003 and in IDAN2008) examine
974 an entire label, not just individual characters. The algorithmic
975 model used in IDNA2003 rejects the label when the final character in
976 a right to left string requires a combining mark in order to be
977 correctly represented.
979 That prohibition is not acceptable for writing systems for languages
980 written with consonantal alphabets to which diacritical vocalic
981 systems are applied, and for languages with orthographies derived
982 from them where the combining marks may have different functionality.
983 In both cases the combining marks can be essential components of the
984 orthography. Examples of this are Yiddish, written with an extended
985 Hebrew script, and Dhivehi (the official language of Maldives) which
986 is written in the Thaana script (which is, in turn, derived from the
987 Arabic script). IDNA2008 removes the restriction on final combining
988 characters with a new set of rules for right to left scripts and
989 their characters. Those new rules are specified in [IDNA2008-Bidi].
991 5. IDNs and the Robustness Principle
993 The "Robustness Principle" is often stated as "Be conservative about
994 what you send and liberal in what you accept" (See, e.g., Section
995 1.2.2 of the applications-layer Host Requirements specification
996 [RFC1123]) This principle applies to IDNA. In applying the principle
997 to registries as the source ("sender") of all registered and useful
998 IDNs, registries are responsible for being conservative about what
999 they register and put out in the Internet. For IDNs to work well,
1000 zone administrators (registries) must have and require sensible
1001 policies about what is registered -- conservative policies -- and
1002 implement and enforce them.
1004 Conversely, lookup applications are expected to reject labels that
1005 clearly violate global (protocol) rules (no one has ever seriously
1006 claimed that being liberal in what is accepted requires being
1007 stupid). However, once one gets past such global rules and deals
1008 with anything sensitive to script or locale, it is necessary to
1009 assume that garbage has not been placed into the DNS, i.e., one must
1010 be liberal about what one is willing to look up in the DNS rather
1011 than guessing about whether it should have been permitted to be
1012 registered.
1014 If a string cannot be successfully found in the DNS after the lookup
1015 processing described here, it makes no difference whether it simply
1016 wasn't registered or was prohibited by some rule at the registry.
1017 Application implementors should be aware that where DNS wildcards are
1018 used, the ability to successfully resolve a name does not guarantee
1019 that it was actually registered.
1021 6. Front-end and User Interface Processing for Lookup
1023 Domain names may be identified and processed in many contexts. They
1024 may be typed in by users either by themselves or embedded in an
1025 identifier such as email addresses, URIs, or IRIs. They may occur in
1026 running text or be processed by one system after being provided in
1027 another. Systems may try to normalize URLs to determine (or guess)
1028 whether a reference is valid or two references point to the same
1029 object without actually looking the objects up (comparison without
1030 lookup is necessary for URI types that are not intended to be
1031 resolved). Some of these goals may be more easily and reliably
1032 satisfied than others. While there are strong arguments for any
1033 domain name that is placed "on the wire" -- transmitted between
1034 systems -- to be in the zero-ambiguity forms of A-labels, it is
1035 inevitable that programs that process domain names will encounter
1036 U-labels or variant forms.
1038 An application that implements the IDNA protocol [IDNA2008-Protocol]
1039 will always take any user input and convert it to a set of Unicode
1040 code points. That user input may be acquired by any of several
1041 different input methods, all with differing conversion processes to
1042 be taken into consideration (e.g., typed on a keyboard, written by
1043 hand onto some sort of digitizer, spoken into a microphone and
1044 interpreted by a speech-to-text engine, etc.). The process of taking
1045 any particular user input and mapping it into a Unicode code point
1046 may be a simple one: If a user strikes the "A" key on a US English
1047 keyboard, without any modifiers such as the "Shift" key held down, in
1048 order to draw a Latin small letter A ("a"), many (perhaps most)
1049 modern operating system input methods will produce to the calling
1050 application the code point U+0061, encoded in a single octet.
1052 Sometimes the process is somewhat more complicated: a user might
1053 strike a particular set of keys to represent a combining macron
1054 followed by striking the "A" key in order to draw a Latin small
1055 letter A with a macron above it. Depending on the operating system,
1056 the input method chosen by the user, and even the parameters with
1057 which the application communicates with the input method, the result
1058 might be the code point U+0101 (encoded as two octets in UTF-8 or
1059 UTF-16, four octets in UTF-32, etc.), the code point U+0061 followed
1060 by the code point U+0304 (again, encoded in three or more octets,
1061 depending upon the encoding used) or even the code point U+FF41
1062 followed by the code point U+0304 (and encoded in some form). And
1063 these examples leave aside the issue of operating systems and input
1064 methods that do not use Unicode code points for their character set.
1066 In every case, applications (with the help of the operating systems
1067 on which they run and the input methods used) need to perform a
1068 mapping from user input into Unicode code points.
1070 The original version of the IDNA protocol [RFC3490] used a model
1071 whereby input was taken from the user, mapped (via whatever input
1072 method mechanisms were used) to a set of Unicode code points, and
1073 then further mapped to a set of Unicode code points using the
1074 Nameprep profile specified in [RFC3491]. In this procedure, there
1075 are two separate mapping steps: First, a mapping done by the input
1076 method (which might be controlled by the operating system, the
1077 application, or some combination) and then a second mapping performed
1078 by the Nameprep portion of the IDNA protocol. The mapping done in
1079 Nameprep includes a particular mapping table to re-map some
1080 characters to other characters, a particular normalization, and a set
1081 of prohibited characters.
1083 Note that the result of the two step mapping process means that the
1084 mapping chosen by the operating system or application in the first
1085 step might differ significantly from the mapping supplied by the
1086 Nameprep profile in the second step. This has advantages and
1087 disadvantages. Of course, the second mapping regularizes what gets
1088 looked up in the DNS, making for better interoperability between
1089 implementations which use the Nameprep mapping. However, the
1090 application or operating system may choose mappings in their input
1091 methods, which when passed through the second (Nameprep) mapping
1092 result in characters that are "surprising" to the end user.
1094 The other important feature of the original version of the IDNA
1095 protocol is that, with very few exceptions, it assumes that any set
1096 of Unicode code points provided to the Nameprep mapping can be mapped
1097 into a string of Unicode code points that are "sensible", even if
1098 that means mapping some code points to nothing (that is, removing the
1099 code points from the string). This allowed maximum flexibility in
1100 input strings.
1102 The present version of IDNA differs significantly in approach from
1103 the original version. First and foremost, it does not provide
1104 explicit mapping instructions. Instead, it assumes that the
1105 application (perhaps via an operating system input method) will do
1106 whatever mapping it requires to convert input into Unicode code
1107 points. This has the advantage of giving flexibility to the
1108 application to choose a mapping that is suitable for its user given
1109 specific user requirements, and avoids the two-step mapping of the
1110 original protocol. Instead of a mapping, the current version of IDNA
1111 provides a set of categories that can be used to specify the valid
1112 code points allowed in a domain name.
1114 In principle, an application ought to take user input of a domain
1115 name and convert it to the set of Unicode code points that represent
1116 the domain name the user intends. As a practical matter, of course,
1117 determining user intent is a tricky business, so an application needs
1118 to choose a reasonable mapping from user input. That may differ
1119 based on the particular circumstances of a user, depending on locale,
1120 language, type of input method, etc. It is up to the application to
1121 make a reasonable choice.
1123 7. Migration from IDNA2003 and Unicode Version Synchronization
1125 7.1. Design Criteria
1127 As mentioned above and in RFC 4690, two key goals of the IDNA2008
1128 design are
1130 o to enable applications to be agnostic about whether they are being
1131 run in environments supporting any Unicode version from 3.2
1132 onward,
1134 o to permit incrementally adding new characters, character groups,
1135 scripts, and other character collections as they are incorporated
1136 into Unicode, doing so without disruption and, in the long term,
1137 without "heavy" processes (an IETF consensus process is required
1138 by the IDNA2008 specifications and is expected to be required and
1139 used until significant experience accumulates with IDNA operations
1140 and new versions of Unicode).
1142 7.1.1. Summary and Discussion of IDNA Validity Criteria
1144 The general criteria for a label to be considered IDNA-valid are (the
1145 actual rules are rigorously defined in the "Protocol" and "Tables"
1146 documents):
1148 o The characters are "letters", marks needed to form letters,
1149 numerals, or other code points used to write words in some
1150 language. Symbols, drawing characters, and various notational
1151 characters are intended to be permanently excluded. There is no
1152 evidence that they are important enough to Internet operations or
1153 internationalization to justify expansion of domain names beyond
1154 the general principle of "letters, digits, and hyphen".
1155 (Additional discussion and rationale for the symbol decision
1156 appears in Section 7.6).
1158 o Other than in very exceptional cases, e.g., where they are needed
1159 to write substantially any word of a given language, punctuation
1160 characters are excluded. The fact that a word exists is not proof
1161 that it should be usable in a DNS label and DNS labels are not
1162 expected to be usable for multiple-word phrases (although they are
1163 certainly not prohibited if the conventions and orthography of a
1164 particular language cause that to be possible).
1166 o Characters that are unassigned (have no character assignment at
1167 all) in the version of Unicode being used by the registry or
1168 application are not permitted, even on lookup. The issues
1169 involved in this decision are discussed in Section 7.7.
1171 o Any character that is mapped to another character by a current
1172 version of NFKC is prohibited as input to IDNA (for either
1173 registration or lookup). With a few exceptions, this principle
1174 excludes any character mapped to another by Nameprep [RFC3491].
1176 The principles above drive the design of rules that are specified
1177 exactly in [IDNA2008-Tables]. Those rules identify the characters
1178 that are IDNA-valid. The rules themselves are normative, and the
1179 tables are derived from them, rather than vice versa.
1181 7.1.2. Labels in Registration
1183 Any label registered in a DNS zone must be validated -- i.e., the
1184 criteria for that label must be met -- in order for applications to
1185 work as intended. This principle is not new. For example, since the
1186 DNS was first deployed, zone administrators have been expected to
1187 verify that names meet "hostname" requirements [RFC0952] where those
1188 requirements are imposed by the expected applications. Other
1189 applications contexts, such as the later addition of special service
1190 location formats [RFC2782] imposed new requirements on zone
1191 administrators. For zones that will contain IDNs, support for
1192 Unicode version-independence requires restrictions on all strings
1193 placed in the zone. In particular, for such zones:
1195 o Any label that appears to be an A-label, i.e., any label that
1196 starts in "xn--", must be IDNA-valid, i.e., they must be valid
1197 A-labels, as discussed in Section 2 above.
1199 o The Unicode tables (i.e., tables of code points, character
1200 classes, and properties) and IDNA tables (i.e., tables of
1201 contextual rules such as those that appear in the Tables
1202 document), must be consistent on the systems performing or
1203 validating labels to be registered. Note that this does not
1204 require that tables reflect the latest version of Unicode, only
1205 that all tables used on a given system are consistent with each
1206 other.
1208 Under this model, registry tables will need to be updated (both the
1209 Unicode-associated tables and the tables of permitted IDN characters)
1210 to enable a new script or other set of new characters. The registry
1211 will not be affected by newer versions of Unicode, or newly-
1212 authorized characters, until and unless it wishes to support them.
1213 The zone administrator is responsible for verifying IDNA-validity as
1214 well as its local policies -- a more extensive set of checks than are
1215 required for looking up the labels. Systems looking up or resolving
1216 DNS labels, especially IDN DNS labels, must be able to assume that
1217 applicable registration rules were followed for names entered into
1218 the DNS.
1220 7.1.3. Labels in Lookup
1222 Anyone looking up a label in a DNS zone is required to
1224 o Maintain IDNA and Unicode tables that are consistent with regard
1225 to versions, i.e., unless the application actually executes the
1226 classification rules in [IDNA2008-Tables], its IDNA tables must be
1227 derived from the version of Unicode that is supported more
1228 generally on the system. As with registration, the tables need
1229 not reflect the latest version of Unicode but they must be
1230 consistent.
1232 o Validate the characters in labels to be looked up only to the
1233 extent of determining that the U-label does not contain
1234 "DISALLOWED" code points or code points that are unassigned in its
1235 version of Unicode.
1237 o Validate the label itself for conformance with a small number of
1238 whole-label rules. In particular, it must verify that
1240 * there are no leading combining marks,
1242 * the "bidi" conditions are met if right to left characters
1243 appear,
1245 * any required contextual rules are available, and
1247 * any contextual rules that are associated with Joiner Controls
1248 (and "CONTEXTJ" characters more generally) are tested.
1250 o Do not reject labels based on other contextual rules about
1251 characters, including mixed-script label prohibitions. Such rules
1252 may be used to influence presentation decisions in the user
1253 interface, but not to avoid looking up domain names.
1255 Lookup applications that following these rules, rather than having
1256 their own criteria for rejecting lookup attempts, are not sensitive
1257 to version incompatibilities with the particular zone registry
1258 associated with the domain name except for labels containing
1259 characters recently added to Unicode.
1261 An application or client that processes names according to this
1262 protocol and then resolves them in the DNS will be able to locate any
1263 name that is registered, as long as those registrations are IDNA-
1264 valid and its version of the IDNA tables is sufficiently up-to-date
1265 to interpret all of the characters in the label. Messages to users
1266 should distinguish between "label contains an unallocated code point"
1267 and other types of lookup failures. A failure on the basis of an old
1268 version of Unicode may lead the user to a desire to upgrade to a
1269 newer version, but will have no other ill effects (this is consistent
1270 with behavior in the transition to the DNS when some hosts could not
1271 yet handle some forms of names or record types).
1273 7.2. Changes in Character Interpretations
1275 In those scripts that make case distinctions, there are a few
1276 characters for which an obvious and unique upper case character has
1277 not historically been available to match a lower case one or vice
1278 versa. For those characters, the mappings used in constructing the
1279 Stringprep tables for IDNA2003, performed using the Unicode CaseFold
1280 operation (See Section 5.8 of the Unicode Standard [Unicode51]),
1281 generate different characters or sets of characters. Those
1282 operations are not reversible and lose even more information than
1283 traditional upper case or lower case transformations, but are more
1284 useful than those transformations for comparison purposes. Two
1285 notable characters of this type are the German character Eszett
1286 (Sharp S, U+00DF) and the Greek Final Form Sigma (U+03C2). The
1287 former is case-folded to the ASCII string "ss", the latter to a
1288 medial (Lower Case) Sigma (U+03C3).
1290 The decision to eliminate mandatory and standardized mappings,
1291 including case folding, from the IDNA2008 protocol in order to make
1292 A-labels and U-labels idempotent made these characters problematic.
1293 If they were to be disallowed, important words and mnemonics could
1294 not be written in orthographically reasonable ways. If they were to
1295 be permitted as distinct characters, there would be no information
1296 loss and registries would have more flexibility, but IDNA2003 and
1297 IDNA2008 lookups might result in different A-labels.
1299 With the understanding that there would be incompatibility either way
1300 but a judgment that the incompatibility was not significant enough to
1301 justify a prefix change, the WG concluded that Eszett and Final Form
1302 Sigma should be treated as distinct and Protocol-Valid characters.
1304 Registries, especially those maintaining zones for third parties,
1305 must decide how to introduce a new service in a way that does not
1306 create confusion or significantly weaken or invalidate existing
1307 identifiers. This is not a new problem; registries were faced with
1308 similar issues when IDNs were introduced and when other new forms of
1309 strings have been permitted as labels.
1311 There are several approaches to problems of this type. Without any
1312 preference or claim to completeness, some of these, all of which have
1313 been used by registries in the past for similar transitions, are:
1315 o Do not permit use of the newly-available character at the registry
1316 level. This might cause lookup failures if a domain name were to
1317 be written with the expectation of the IDNA2003 mapping behavior,
1318 but would eliminate any possibility of false matches.
1320 o Hold a "sunrise"-like arrangement in which holders of labels
1321 containing "ss" in the Eszett case or Lower Case Sigma are given
1322 priority (and perhaps other benefits) for registering the
1323 corresponding string containing Eszett or Final Sigma
1324 respectively.
1326 o Adopt some sort of "variant" approach in which registrants obtain
1327 labels with both character forms.
1329 o Adopt a different form of "variant" approach in which registration
1330 of additional names is either not permitted at all or permitted
1331 only by the registrant who already has one of the names.
1333 7.3. Character Mapping
1335 As discussed at length in Section 6, IDNA2003, via Nameprep (see
1336 Section 7.5), mapped many characters into related ones. Those
1337 mappings no longer exist as requirements in IDNA2008. These
1338 specifications strongly prefer that only A-labels or U-labels be used
1339 in protocol contexts and as much as practical more generally.
1340 IDNA2008 does anticipate situations in which some mapping at the time
1341 of user input into lookup applications is appropriate and desirable.
1342 The issues are discussed in Section 6 and specific recommendations
1343 are made in [IDNA2008-Mapping].
1345 7.4. The Question of Prefix Changes
1347 The conditions that would require a change in the IDNA ACE prefix
1348 ("xn--" for the version of IDNA specified in [RFC3490]) have been a
1349 great concern to the community. A prefix change would clearly be
1350 necessary if the algorithms were modified in a manner that would
1351 create serious ambiguities during subsequent transition in
1352 registrations. This section summarizes our conclusions about the
1353 conditions under which changes in prefix would be necessary and the
1354 implications of such a change.
1356 7.4.1. Conditions Requiring a Prefix Change
1358 An IDN prefix change is needed if a given string would be looked up
1359 or otherwise interpreted differently depending on the version of the
1360 protocol or tables being used. An IDNA upgrade would require a
1361 prefix change if, and only if, one of the following four conditions
1362 were met:
1364 1. The conversion of an A-label to Unicode (i.e., a U-label) yields
1365 one string under IDNA2003 (RFC3490) and a different string under
1366 IDNA2008.
1368 2. In a significant number of cases, an input string that is valid
1369 under IDNA2003 and also valid under IDNA2008 yields two different
1370 A-labels with the different versions. This condition is believed
1371 to be essentially equivalent to the one above except for a very
1372 small number of edge cases which may not justify a prefix change
1373 (See Section 7.2).
1375 Note that if the input string is valid under one version and not
1376 valid under the other, this condition does not apply. See the
1377 first item in Section 7.4.2, below.
1379 3. A fundamental change is made to the semantics of the string that
1380 is inserted in the DNS, e.g., if a decision were made to try to
1381 include language or script information in the encoding in
1382 addition to the string itself.
1384 4. A sufficiently large number of characters is added to Unicode so
1385 that the Punycode mechanism for block offsets can no longer
1386 reference the higher-numbered planes and blocks. This condition
1387 is unlikely even in the long term and certain not to arise in the
1388 next several years.
1390 7.4.2. Conditions Not Requiring a Prefix Change
1392 As a result of the principles described above, none of the following
1393 changes require a new prefix:
1395 1. Prohibition of some characters as input to IDNA. This may make
1396 names that are now registered inaccessible, but does not change
1397 those names.
1399 2. Adjustments in IDNA tables or actions, including normalization
1400 definitions, that affect characters that were already invalid
1401 under IDNA2003.
1403 3. Changes in the style of the IDNA definition that does not alter
1404 the actions performed by IDNA.
1406 7.4.3. Implications of Prefix Changes
1408 While it might be possible to make a prefix change, the costs of such
1409 a change are considerable. Registries could not convert all IDNA2003
1410 ("xn--") registrations to a new form at the same time and synchronize
1411 that change with applications supporting lookup. Unless all existing
1412 registrations were simply to be declared invalid (and perhaps even
1413 then) systems that needed to support both labels with old prefixes
1414 and labels with new ones would first process a putative label under
1415 the IDNA2008 rules and try to look it up and then, if it were not
1416 found, would process the label under IDNA2003 rules and look it up
1417 again. That process could significantly slow down all processing
1418 that involved IDNs in the DNS especially since a fully-qualified name
1419 might contain a mixture of labels that were registered with the old
1420 and new prefixes. That would make DNS caching very difficult. In
1421 addition, looking up the same input string as two separate A-labels
1422 creates some potential for confusion and attacks, since the labels
1423 could map to different targets and then resolve to different entries
1424 in the DNS.
1426 Consequently, a prefix change is to be avoided if at all possible,
1427 even if it means accepting some IDNA2003 decisions about character
1428 distinctions as irreversible and/or giving special treatment to edge
1429 cases.
1431 7.5. Stringprep Changes and Compatibility
1433 The Nameprep [RFC3491] specification, a key part of IDNA2003, is a
1434 profile of Stringprep [RFC3454]. While Nameprep is a Stringprep
1435 profile specific to IDNA, Stringprep is used by a number of other
1436 protocols. Were Stringprep to be modified by IDNA2008, those changes
1437 to improve the handling of IDNs could cause problems for non-DNS
1438 uses, most notably if they affected identification and authentication
1439 protocols. Several elements of IDNA2008 give interpretations to
1440 strings prohibited under IDNA2003 or prohibit strings that IDNA2003
1441 permitted. Those elements include the proposed new inclusion tables
1442 [IDNA2008-Tables], the reduction in the number of characters
1443 permitted as input for registration or lookup (Section 3), and even
1444 the proposed changes in handling of right to left strings
1445 [IDNA2008-Bidi]. IDNA2008 does not use Nameprep or Stringprep at
1446 all, so there are no side-effect changes to other protocols.
1448 It is particularly important to keep IDNA processing separate from
1449 processing for various security protocols because some of the
1450 constraints that are necessary for smooth and comprehensible use of
1451 IDNs may be unwanted or undesirable in other contexts. For example,
1452 the criteria for good passwords or passphrases are very different
1453 from those for desirable IDNs: passwords should be hard to guess,
1454 while domain names should normally be easily memorable. Similarly,
1455 internationalized SCSI identifiers and other protocol components are
1456 likely to have different requirements than IDNs.
1458 7.6. The Symbol Question
1460 One of the major differences between this specification and the
1461 original version of IDNA is that the original version permitted non-
1462 letter symbols of various sorts, including punctuation and line-
1463 drawing symbols, in the protocol. They were always discouraged in
1464 practice. In particular, both the "IESG Statement" about IDNA and
1465 all versions of the ICANN Guidelines specify that only language
1466 characters be used in labels. This specification disallows symbols
1467 entirely. There are several reasons for this, which include:
1469 1. As discussed elsewhere, the original IDNA specification assumed
1470 that as many Unicode characters as possible should be permitted,
1471 directly or via mapping to other characters, in IDNs. This
1472 specification operates on an inclusion model, extrapolating from
1473 the original "hostname" rules (LDH, see [IDNA2008-Defs]) -- which
1474 have served the Internet very well -- to a Unicode base rather
1475 than an ASCII base.
1477 2. Symbol names are more problematic than letters because there may
1478 be no general agreement on whether a particular glyph matches a
1479 symbol; there are no uniform conventions for naming; variations
1480 such as outline, solid, and shaded forms may or may not exist;
1481 and so on. As just one example, consider a "heart" symbol as it
1482 might appear in a logo that might be read as "I love...". While
1483 the user might read such a logo as "I love..." or "I heart...",
1484 considerable knowledge of the coding distinctions made in Unicode
1485 is needed to know that there more than one "heart" character
1486 (e.g., U+2665, U+2661, and U+2765) and how to describe it. These
1487 issues are of particular importance if strings are expected to be
1488 understood or transcribed by the listener after being read out
1489 loud.
1491 3. Design of a screen reader used by blind Internet users who must
1492 listen to renderings of IDN domain names and possibly reproduce
1493 them on the keyboard becomes considerably more complicated when
1494 the names of characters are not obvious and intuitive to anyone
1495 familiar with the language in question.
1497 4. As a simplified example of this, assume one wanted to use a
1498 "heart" or "star" symbol in a label. This is problematic because
1499 those names are ambiguous in the Unicode system of naming (the
1500 actual Unicode names require far more qualification). A user or
1501 would-be registrant has no way to know -- absent careful study of
1502 the code tables -- whether it is ambiguous (e.g., where there are
1503 multiple "heart" characters) or not. Conversely, the user seeing
1504 the hypothetical label doesn't know whether to read it -- try to
1505 transmit it to a colleague by voice -- as "heart", as "love", as
1506 "black heart", or as any of the other examples below.
1508 5. The actual situation is even worse than this. There is no
1509 possible way for a normal, casual, user to tell the difference
1510 between the hearts of U+2665 and U+2765 and the stars of U+2606
1511 and U+2729 or the without somehow knowing to look for a
1512 distinction. We have a white heart (U+2661) and few black
1513 hearts. Consequently, describing a label as containing a heart
1514 hopelessly ambiguous: we can only know that it contains one of
1515 several characters that look like hearts or have "heart" in their
1516 names. In cities where "Square" is a popular part of a location
1517 name, one might well want to use a square symbol in a label as
1518 well and there are far more squares of various flavors in Unicode
1519 than there are hearts or stars.
1521 The consequence of these ambiguities is that symbols are a very poor
1522 basis for reliable communication. Consistent with this conclusion,
1523 the Unicode standard recommends that strings used in identifiers not
1524 contain symbols or punctuation [Unicode-UAX31]. Of course, these
1525 difficulties with symbols do not arise with actual pictographic
1526 languages and scripts which would be treated like any other language
1527 characters; the two should not be confused.
1529 7.7. Migration Between Unicode Versions: Unassigned Code Points
1531 In IDNA2003, labels containing unassigned code points are looked up
1532 on the assumption that, if they appear in labels and can be mapped
1533 and then resolved, the relevant standards must have changed and the
1534 registry has properly allocated only assigned values.
1536 In the protocol described in these documents, strings containing
1537 unassigned code points must not be either looked up or registered.
1538 In summary, the status of an unassigned character with regard to the
1539 DISALLOWED, PROTOCOL-VALID, and CONTEXTUAL RULE REQUIRED categories
1540 cannot be evaluated until a character is actually assigned and known.
1541 There are several reasons for this, with the most important ones
1542 being:
1544 o Tests involving the context of characters (e.g., some characters
1545 being permitted only adjacent to others of specific types) and
1546 integrity tests on complete labels are needed. Unassigned code
1547 points cannot be permitted because one cannot determine whether
1548 particular code points will require contextual rules (and what
1549 those rules should be) before characters are assigned to them and
1550 the properties of those characters fully understood.
1552 o It cannot be known in advance, and with sufficient reliability,
1553 whether a newly-assigned code point will be associated with a
1554 character that would be disallowed by the rules in
1555 [IDNA2008-Tables] (such as a compatibility character). In
1556 IDNA2003, since there is no direct dependency on NFKC (many of the
1557 entries in Stringprep's tables are based on NFKC, but IDNA2003
1558 depends only on Stringprep), allocation of a compatibility
1559 character might produce some odd situations, but it would not be a
1560 problem. In IDNA2008, where compatibility characters are
1561 DISALLOWED unless character-specific exceptions are made,
1562 permitting strings containing unassigned characters to be looked
1563 up would violate the principle that characters in DISALLOWED are
1564 not looked up.
1566 o The Unicode Standard specifies that an unassigned code point
1567 normalizes (and, where relevant, case folds) to itself. If the
1568 code point is later assigned to a character, and particularly if
1569 the newly-assigned code point has a combining class that
1570 determines its placement relative to other combining characters,
1571 it could normalize to some other code point or sequence.
1573 It is possible to argue that the issues above are not important and
1574 that, as a consequence, it is better to retain the principle of
1575 looking up labels even if they contain unassigned characters because
1576 all of the important scripts and characters have been coded as of
1577 Unicode 5.1 and hence unassigned code points will be assigned only to
1578 obscure characters or archaic scripts. Unfortunately, that does not
1579 appear to be a safe assumption for at least two reasons. First, much
1580 the same claim of completeness has been made for earlier versions of
1581 Unicode. The reality is that a script that is obscure to much of the
1582 world may still be very important to those who use it. Cultural and
1583 linguistic preservation principles make it inappropriate to declare
1584 the script of no importance in IDNs. Second, we already have
1585 counterexamples in, e.g., the relationships associated with new Han
1586 characters being added (whether in the BMP or in Unicode Plane 2).
1588 Independent of the technical transition issues identified above, it
1589 can be observed that any addition of characters to an existing script
1590 to make it easier to use or to better accommodate particular
1591 languages may lead to transition issues. Such changes may change the
1592 preferred form for writing a particular string, changes that may be
1593 reflected, e.g., in keyboard transition modules that would
1594 necessarily be different from those for earlier versions of Unicode
1595 where the newer characters may not exist. This creates an inherent
1596 transition problem because attempts to access labels may use either
1597 the old or the new conventions, requiring registry action whether the
1598 older conventions were used in labels or not. The need to consider
1599 transition mechanisms is inherent to evolution of Unicode to better
1600 accommodate writing systems and is independent of how IDNs are
1601 represented in the DNS or how transitions among versions of those
1602 mechanisms occur. The requirement for transitions of this type is
1603 illustrated by the addition of Malayalam Chillu in Unicode 5.1.0.
1605 7.8. Other Compatibility Issues
1607 The 2003 IDNA model includes several odd artifacts of the context in
1608 which it was developed. Many, if not all, of these are potential
1609 avenues for exploits, especially if the registration process permits
1610 "source" names (names that have not been processed through IDNA and
1611 Nameprep) to be registered. As one example, since the character
1612 Eszett, used in German, is mapped by IDNA2003 into the sequence "ss"
1613 rather than being retained as itself or prohibited, a string
1614 containing that character but that is otherwise in ASCII is not
1615 really an IDN (in the U-label sense defined above) at all. After
1616 Nameprep maps the Eszett out, the result is an ASCII string and so
1617 does not get an xn-- prefix, but the string that can be displayed to
1618 a user appears to be an IDN. The newer version of the protocol
1619 eliminates this artifact. A character is either permitted as itself
1620 or it is prohibited; special cases that make sense only in a
1621 particular linguistic or cultural context can be dealt with as
1622 localization matters where appropriate.
1624 8. Name Server Considerations
1626 8.1. Processing Non-ASCII Strings
1628 Existing DNS servers do not know the IDNA rules for handling non-
1629 ASCII forms of IDNs, and therefore need to be shielded from them.
1630 All existing channels through which names can enter a DNS server
1631 database (for example, master files (as described in RFC 1034) and
1632 DNS update messages [RFC2136]) are IDN-unaware because they predate
1633 IDNA. Other sections of this document provide the needed shielding
1634 by ensuring that internationalized domain names entering DNS server
1635 databases through such channels have already been converted to their
1636 equivalent ASCII A-label forms.
1638 Because of the distinction made between the algorithms for
1639 Registration and Lookup in [IDNA2008-Protocol] (a domain name
1640 containing only ASCII codepoints can not be converted to an A-label),
1641 there can not be more than one A-label form for any given U-label.
1643 As specified in RFC 2181 [RFC2181], the DNS protocol explicitly
1644 allows domain labels to contain octets beyond the ASCII range
1645 (0000..007F), and this document does not change that. However,
1646 although the interpretation of octets 0080..00FF is well-defined in
1647 the DNS, many application protocols support only ASCII labels and
1648 there is no defined interpretation of these non-ASCII octets as
1649 characters and, in particular, no interpretation of case-independent
1650 matching for them (see, e.g., [RFC4343]). If labels containing these
1651 octets are returned to applications, unpredictable behavior could
1652 result. The A-label form, which cannot contain those characters, is
1653 the only standard representation for internationalized labels in the
1654 DNS protocol.
1656 8.2. DNSSEC Authentication of IDN Domain Names
1658 DNS Security (DNSSEC) [RFC2535] is a method for supplying
1659 cryptographic verification information along with DNS messages.
1660 Public Key Cryptography is used in conjunction with digital
1661 signatures to provide a means for a requester of domain information
1662 to authenticate the source of the data. This ensures that it can be
1663 traced back to a trusted source, either directly or via a chain of
1664 trust linking the source of the information to the top of the DNS
1665 hierarchy.
1667 IDNA specifies that all internationalized domain names served by DNS
1668 servers that cannot be represented directly in ASCII MUST use the
1669 A-label form. Conversion to A-labels MUST be performed prior to a
1670 zone being signed by the private key for that zone. Because of this
1671 ordering, it is important to recognize that DNSSEC authenticates a
1672 domain name containing A-labels or conventional LDH-labels, not
1673 U-labels. In the presence of DNSSEC, no form of a zone file or query
1674 response that contains a U-label may be signed or the signature
1675 validated.
1677 One consequence of this for sites deploying IDNA in the presence of
1678 DNSSEC is that any special purpose proxies or forwarders used to
1679 transform user input into IDNs must be earlier in the lookup flow
1680 than DNSSEC authenticating nameservers for DNSSEC to work.
1682 8.3. Root and other DNS Server Considerations
1684 IDNs in A-label form will generally be somewhat longer than current
1685 domain names, so the bandwidth needed by the root servers is likely
1686 to go up by a small amount. Also, queries and responses for IDNs
1687 will probably be somewhat longer than typical queries historically,
1688 so EDNS0 [RFC2671] support may be more important (otherwise, queries
1689 and responses may be forced to go to TCP instead of UDP).
1691 9. Internationalization Considerations
1693 DNS labels and fully-qualified domain names provide mnemonics that
1694 assist in identifying and referring to resources on the Internet.
1695 IDNs expand the range of those mnemonics to include those based on
1696 languages and character sets other than Western European and Roman-
1697 derived ones. But domain "names" are not, in general, words in any
1698 language. The recommendations of the IETF policy on character sets
1699 and languages, (BCP 18 [RFC2277]) are applicable to situations in
1700 which language identification is used to provide language-specific
1701 contexts. The DNS is, by contrast, global and international and
1702 ultimately has nothing to do with languages. Adding languages (or
1703 similar context) to IDNs generally, or to DNS matching in particular,
1704 would imply context dependent matching in DNS, which would be a very
1705 significant change to the DNS protocol itself. It would also imply
1706 that users would need to identify the language associated with a
1707 particular label in order to look that label up. That knowledge is
1708 generally not available because many labels are not words in any
1709 language and some may be words in more than one.
1711 10. IANA Considerations
1713 This section gives an overview of IANA registries required for IDNA.
1715 The actual definitions of, and specifications for, the first two,
1716 which must be newly-created for IDNA2008, appear in
1717 [IDNA2008-Tables]. This document describes the registries but does
1718 not specify any IANA actions.
1720 10.1. IDNA Character Registry
1722 The distinction among the major categories "UNASSIGNED",
1723 "DISALLOWED", "PROTOCOL-VALID", and "CONTEXTUAL RULE REQUIRED" is
1724 made by special categories and rules that are integral elements of
1725 [IDNA2008-Tables]. While not normative, an IANA registry of
1726 characters and scripts and their categories, updated for each new
1727 version of Unicode and the characters it contains, will be convenient
1728 for programming and validation purposes. The details of this
1729 registry are specified in [IDNA2008-Tables].
1731 10.2. IDNA Context Registry
1733 IANA will create and maintain a list of approved contextual rules for
1734 characters that are defined in the IDNA Character Registry list as
1735 requiring a Contextual Rule (i.e., the types of rule described in
1736 Section 3.1.2). The details for those rules appear in
1737 [IDNA2008-Tables].
1739 10.3. IANA Repository of IDN Practices of TLDs
1741 This registry, historically described as the "IANA Language Character
1742 Set Registry" or "IANA Script Registry" (both somewhat misleading
1743 terms) is maintained by IANA at the request of ICANN. It is used to
1744 provide a central documentation repository of the IDN policies used
1745 by top level domain (TLD) registries who volunteer to contribute to
1746 it and is used in conjunction with ICANN Guidelines for IDN use.
1748 It is not an IETF-managed registry and, while the protocol changes
1749 specified here may call for some revisions to the tables, these
1750 specifications have no direct effect on that registry and no IANA
1751 action is required as a result.
1753 11. Security Considerations
1755 11.1. General Security Issues with IDNA
1757 This document is purely explanatory and informational and
1758 consequently introduces no new security issues. It would, of course,
1759 be a poor idea for someone to try to implement from it; such an
1760 attempt would almost certainly lead to interoperability problems and
1761 might lead to security ones. A discussion of security issues with
1762 IDNA, including some relevant history, appears in [IDNA2008-Defs].
1764 12. Acknowledgments
1766 The editor and contributors would like to express their thanks to
1767 those who contributed significant early (pre-WG) review comments,
1768 sometimes accompanied by text, especially Mark Davis, Paul Hoffman,
1769 Simon Josefsson, and Sam Weiler. In addition, some specific ideas
1770 were incorporated from suggestions, text, or comments about sections
1771 that were unclear supplied by Vint Cerf, Frank Ellerman, Michael
1772 Everson, Asmus Freytag, Erik van der Poel, Michel Suignard, and Ken
1773 Whistler. Thanks are also due to Vint Cerf, Lisa Dusseault, Debbie
1774 Garside, and Jefsey Morfin for conversations that led to considerable
1775 improvements in the content of this document.
1777 A meeting was held on 30 January 2008 to attempt to reconcile
1778 differences in perspective and terminology about this set of
1779 specifications between the design team and members of the Unicode
1780 Technical Consortium. The discussions at and subsequent to that
1781 meeting were very helpful in focusing the issues and in refining the
1782 specifications. The active participants at that meeting were (in
1783 alphabetic order as usual) Harald Alvestrand, Vint Cerf, Tina Dam,
1784 Mark Davis, Lisa Dusseault, Patrik Faltstrom (by telephone), Cary
1785 Karp, John Klensin, Warren Kumari, Lisa Moore, Erik van der Poel,
1786 Michel Suignard, and Ken Whistler. We express our thanks to Google
1787 for support of that meeting and to the participants for their
1788 contributions.
1790 Useful comments and text on the WG versions of the draft were
1791 received from many participants in the IETF "IDNABIS" WG and a number
1792 of document changes resulted from mailing list discussions made by
1793 that group. Marcos Sanz provided specific analysis and suggestions
1794 that were exceptionally helpful in refining the text, as did Vint
1795 Cerf, Mark Davis, Martin Duerst, Andrew Sullivan, and Ken Whistler.
1796 Lisa Dusseault provided extensive editorial suggestions during the
1797 spring of 2009, most of which were incorporated.
1799 As is usual with IETF specifications, while the document represents
1800 rough consensus, it should not be assumed that all participants and
1801 contributors agree with all provisions.
1803 13. Contributors
1805 While the listed editor held the pen, the core of this document and
1806 the initial WG version represents the joint work and conclusions of
1807 an ad hoc design team consisting of the editor and, in alphabetic
1808 order, Harald Alvestrand, Tina Dam, Patrik Faltstrom, and Cary Karp.
1809 Considerable material describing mapping principles has been
1810 incorporated from a draft of [IDNA2008-Mapping] by Pete Resnick and
1811 Paul Hoffman. In addition, there were many specific contributions
1812 and helpful comments from those listed in the Acknowledgments section
1813 and others who have contributed to the development and use of the
1814 IDNA protocols.
1816 14. References
1818 14.1. Normative References
1820 [ASCII] American National Standards Institute (formerly United
1821 States of America Standards Institute), "USA Code for
1822 Information Interchange", ANSI X3.4-1968, 1968.
1824 ANSI X3.4-1968 has been replaced by newer versions with
1825 slight modifications, but the 1968 version remains
1826 definitive for the Internet.
1828 [IDNA2008-Bidi]
1829 Alvestrand, H. and C. Karp, "An updated IDNA criterion for
1830 right to left scripts", August 2009, .
1833 [IDNA2008-Defs]
1834 Klensin, J., "Internationalized Domain Names for
1835 Applications (IDNA): Definitions and Document Framework",
1836 August 2009, .
1839 [IDNA2008-Protocol]
1840 Klensin, J., "Internationalized Domain Names in
1841 Applications (IDNA): Protocol", August 2009, .
1844 [IDNA2008-Tables]
1845 Faltstrom, P., "The Unicode Code Points and IDNA",
1846 August 2009, .
1849 A version of this document is available in HTML format at
1850 http://stupid.domain.name/idnabis/
1851 draft-ietf-idnabis-tables-06.html
1853 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
1854 "Internationalizing Domain Names in Applications (IDNA)",
1855 RFC 3490, March 2003.
1857 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
1858 for Internationalized Domain Names in Applications
1859 (IDNA)", RFC 3492, March 2003.
1861 [Unicode-UAX15]
1862 The Unicode Consortium, "Unicode Standard Annex #15:
1863 Unicode Normalization Forms", March 2008,
1864 .
1866 [Unicode51]
1867 The Unicode Consortium, "The Unicode Standard, Version
1868 5.1.0", 2008.
1870 defined by: The Unicode Standard, Version 5.0, Boston, MA,
1871 Addison-Wesley, 2007, ISBN 0-321-48091-0, as amended by
1872 Unicode 5.1.0
1873 (http://www.unicode.org/versions/Unicode5.1.0/).
1875 14.2. Informative References
1877 [BIG5] Institute for Information Industry of Taiwan, "Computer
1878 Chinese Glyph and Character Code Mapping Table, Technical
1879 Report C-26", 1984.
1881 There are several forms and variations and a closely-
1882 related standard, CNS 11643. See the discussion in
1883 Chapter 3 of Lunde, K., CJKV Information Processing,
1884 O'Reilly & Associates, 1999
1886 [GB18030] "Chinese National Standard GB 18030-2000: Information
1887 Technology -- Chinese ideograms coded character set for
1888 information interchange -- Extension for the basic set.",
1889 2000.
1891 [IDNA2008-Mapping]
1892 Resnick, P., "Mapping Characters in IDNA", August 2009, .
1896 [RFC0810] Feinler, E., Harrenstien, K., Su, Z., and V. White, "DoD
1897 Internet host table specification", RFC 810, March 1982.
1899 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
1900 host table specification", RFC 952, October 1985.
1902 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
1903 STD 13, RFC 1034, November 1987.
1905 [RFC1035] Mockapetris, P., "Domain names - implementation and
1906 specification", STD 13, RFC 1035, November 1987.
1908 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
1909 and Support", STD 3, RFC 1123, October 1989.
1911 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
1912 "Dynamic Updates in the Domain Name System (DNS UPDATE)",
1913 RFC 2136, April 1997.
1915 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
1916 Specification", RFC 2181, July 1997.
1918 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
1919 Languages", BCP 18, RFC 2277, January 1998.
1921 [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
1922 RFC 2535, March 1999.
1924 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
1925 RFC 2671, August 1999.
1927 [RFC2673] Crawford, M., "Binary Labels in the Domain Name System",
1928 RFC 2673, August 1999.
1930 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
1931 specifying the location of services (DNS SRV)", RFC 2782,
1932 February 2000.
1934 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
1935 Internationalized Strings ("stringprep")", RFC 3454,
1936 December 2002.
1938 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
1939 Profile for Internationalized Domain Names (IDN)",
1940 RFC 3491, March 2003.
1942 [RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint
1943 Engineering Team (JET) Guidelines for Internationalized
1944 Domain Names (IDN) Registration and Administration for
1945 Chinese, Japanese, and Korean", RFC 3743, April 2004.
1947 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
1948 Identifiers (IRIs)", RFC 3987, January 2005.
1950 [RFC4290] Klensin, J., "Suggested Practices for Registration of
1951 Internationalized Domain Names (IDN)", RFC 4290,
1952 December 2005.
1954 [RFC4343] Eastlake, D., "Domain Name System (DNS) Case Insensitivity
1955 Clarification", RFC 4343, January 2006.
1957 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and
1958 Recommendations for Internationalized Domain Names
1959 (IDNs)", RFC 4690, September 2006.
1961 [RFC4713] Lee, X., Mao, W., Chen, E., Hsu, N., and J. Klensin,
1962 "Registration and Administration Recommendations for
1963 Chinese Domain Names", RFC 4713, October 2006.
1965 [Unicode-Security]
1966 The Unicode Consortium, "Unicode Technical Standard #39:
1967 Unicode Security Mechanisms", August 2008,
1968 .
1970 [Unicode-UAX31]
1971 The Unicode Consortium, "Unicode Standard Annex #31:
1972 Unicode Identifier and Pattern Syntax", March 2008,
1973 .
1975 [Unicode-UTR36]
1976 The Unicode Consortium, "Unicode Technical Report #36:
1977 Unicode Security Considerations", July 2008,
1978 .
1980 Appendix A. Change Log
1982 [[ RFC Editor: Please remove this appendix. ]]
1984 A.1. Changes between Version -00 and Version -01 of
1985 draft-ietf-idnabis-rationale
1987 o Clarified the U-label definition to note that U-labels must
1988 contain at least one non-ASCII character. Also clarified the
1989 relationship among label types.
1991 o Rewrote the discussion of Labels in Registration (Section 7.1.2)
1992 and related text about IDNA-validity (in the "Defs" document as of
1993 -04 of this one) to narrow its focus and remove more general
1994 restrictions. Added a temporary note in line to explain the
1995 situation.
1997 o Changed the "IDNA uses Unicode" statement to focus on
1998 compatibility with IDNA2003 and avoid more general or
1999 controversial assertions.
2001 o Added a discussion of examples to Section 7.1
2003 o Made a number of other small editorial changes and corrections
2004 suggested by Mark Davis.
2006 o Added several more discussion anchors and notes and expanded or
2007 updated some existing ones.
2009 A.2. Version -02
2011 o Trimmed change log, removing information about pre-WG drafts.
2013 o Adjusted discussion of Contextual Rules to match the new location
2014 of the tables and some conceptual material.
2016 o Rewrote the material on preprocessing somewhat.
2018 o Moved the material about relationships with IDNA2003 to be part of
2019 a single section on transitions.
2021 o Removed several placeholders and made editorial changes in
2022 accordance with decisions made at IETF 72 in Dublin and not
2023 disputed on the mailing list.
2025 A.3. Version -03
2027 This special update to the Rationale document is intended to try to
2028 get the discussion of what is normative or not under control. While
2029 the IETF does not normally annotate individual sections of documents
2030 with whether they are normative or not, concerns that we don't know
2031 which is which, claims that some material is normative that would be
2032 problematic if so classified, etc., argue that we should at least be
2033 able to have a clear discussion on the subject.
2035 Two annotations have been applied to sections that might reasonably
2036 be considered normative. One annotation is based on the list of
2037 sections in Mark Davis's note of 29 September (http://
2038 www.alvestrand.no/pipermail/idna-update/2008-September/002667.html).
2039 The other is based on an elaboration of John Klensin's response on 7
2040 October (http://www.alvestrand.no/pipermail/idna-update/2008-October/
2041 002691.html). These should just be considered two suggestions to
2042 illuminate and, one hopes, advance the Working Group's discussions.
2044 Some additional editorial changes have been made, but they are
2045 basically trivial. In the editor's judgment, it is not possible to
2046 make significantly more progress with this document until the matter
2047 of document organization is settled.
2049 A.4. Version -04
2051 o Definitional and other normative material moved to new document
2052 (draft-ietf-idnabis-defs). Version -03 annotations removed.
2054 o Material on differences between IDNA2003 and IDNA2008 moved to an
2055 appendix in Protocol.
2057 o Material left over from the origins of this document as a
2058 preliminary proposal has been removed or rewritten.
2060 o Changes made to reflect consensus call results, including removing
2061 several placeholder notes for discussion.
2063 o Added more material, including discussion of historic scripts, to
2064 Section 3.2 on registration policies.
2066 o Added a new section (Section 7.2) to contain specific discussion
2067 of handling of characters that are interpreted differently in
2068 input to IDNA2003 and 2008.
2070 o Some material, including this section/appendix, rearranged.
2072 A.5. Version -05
2074 o Many small editorial changes, including changes to eliminate the
2075 last vestiges of what appeared to be 2119 language (upper-case
2076 MUST, SHOULD, or MAY) and small adjustments to terminology.
2078 A.6. Version -06
2080 o Removed Security Considerations material and pointed to Defs,
2081 where it now appears as of version 05.
2083 o Started changing uses of "IDNA2008" in running text to "in these
2084 specifications" or the equivalent. These documents are titled
2085 simply "IDNA"; once they are standardized, "the current version"
2086 may be a more appropriate reference than one containing a year.
2087 As discussed on the mailing list, we can and should discuss how to
2088 refer to these documents at an appropriate time (e.g., when we
2089 know when we will be finished) but, in the interim, it seems
2090 appropriate to simply start getting rid of the version-specific
2091 terminology where it can naturally be removed.
2093 o Additional discussion of mappings, etc., especially for case-
2094 sensitivity.
2096 o Clarified relationship to base DNS specifications.
2098 o Consolidated discussion of lookup of unassigned characters.
2100 o More editorial fine-tuning.
2102 A.7. Version -07
2104 o Revised terminology by adding terms: NR-LDH-label, Invalid-A-label
2105 (or False-A-label), R-LDH-label, valid IDNA-label in
2106 Section 1.3.2.
2108 o Moved the "name server considerations" material to this document
2109 from Protocol because it is non-normative and not part of the
2110 protocol itself.
2112 o To improve clarity, redid discussion of the reasons why looking up
2113 unassigned code points is prohibited.
2115 o Editorial and other non-substantive corrections to reflect earlier
2116 errors as well as new definitions and terminology.
2118 A.8. Version -08
2120 o Slight revision to "contextual" discussion (Section 3.1.2) and
2121 moving it to a separate subsection, rather than under "PVALID",
2122 for better parallelism with Tables. Also reflected Mark's
2123 comments about the limitations of the approach.
2125 o Added placeholder notes as reminders of where references to the
2126 other documents need Section numbers. More of these will be added
2127 as needed (feel free to identify relevant places), but the actual
2128 section numbers will not be inserted until the documents are
2129 completely stable, i.e., on their way to the RFC Editor.
2131 A.9. Version -09
2133 o Small editorial changes to clarify transition possibilities.
2135 o Small clarification to the description of DNS "exact match".
2137 o Added discussion of adding characters to an existing script to the
2138 discussion of unassigned code point transitions in Section 7.7.
2140 o Tightened up the discussion of non-ASCII string processing
2141 (Section 8.1) slightly.
2143 o Removed some placeholders and comments that have been around long
2144 enough to be considered acceptable or that no longer seem
2145 necessary for other reasons.
2147 A.10. Version -10
2149 o Extensive editorial improvements, mostly due to suggestions from
2150 Lisa Dusseault.
2152 o Changes required for the new "mapping" approach and document have,
2153 in general, not been incorporated despite several suggestions.
2154 The editor intends to wait until the mapping model is stable, or
2155 at least until -11 of this document, before trying to incorporate
2156 those suggestions.
2158 A.11. Version -11
2160 o Several placeholders for additional material or editing have been
2161 removed since no comments have been received.
2163 o Updated references.
2165 o Corrected an apparent patching error in Section 1.6 and another
2166 one in Section 4.3.
2168 o Adjusted several sections that had not properly reflected removal
2169 of the material that is now in the Definitions document and
2170 removed an unnecessary one.
2172 o New material added to Section 3.2 about registration policy issues
2173 to reflect discussions on the mailing list.
2175 o Incorporated mapping material from the former "Architectural
2176 Principles" of version -01 of the Mapping draft into Section 6 and
2177 removed most of the prior mapping material and explanations.
2179 o Eliminated the former Section 7.3 ("More Flexibility in User
2180 Agents"), moving its material into Section 4.2. The replacement
2181 section is basically a placeholder to retain the mapping issues as
2182 one of the migration topics. Note that this item and the previous
2183 one involve considerable text, so people should check things
2184 carefully.
2186 o Corrected several typographical and editorial errors that don't
2187 fall into any of the above categories.
2189 Author's Address
2191 John C Klensin
2192 1770 Massachusetts Ave, Ste 322
2193 Cambridge, MA 02140
2194 USA
2196 Phone: +1 617 245 1457
2197 Email: john+ietf@jck.com