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