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