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