idnits 2.17.1
draft-ietf-idnabis-defs-13.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 draft header indicates that this document obsoletes RFC3490, but the
abstract doesn't seem to mention this, which it should.
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 (January 7, 2010) is 5223 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII'
-- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode-UAX15'
-- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode52'
-- No information found for draft-ietf-idnabis-mapping - is the name
correct?
-- Obsolete informational reference (is this intentional?): RFC 2616
(Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235)
-- 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 3490
(Obsoleted by RFC 5890, RFC 5891)
-- Obsolete informational reference (is this intentional?): RFC 3491
(Obsoleted by RFC 5891)
-- Obsolete informational reference (is this intentional?): RFC 5246
(Obsoleted by RFC 8446)
Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 13 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. Klensin
3 Internet-Draft January 7, 2010
4 Obsoletes: 3490 (if approved)
5 Intended status: Standards Track
6 Expires: July 11, 2010
8 Internationalized Domain Names for Applications (IDNA): Definitions and
9 Document Framework
10 draft-ietf-idnabis-defs-13.txt
12 Abstract
14 This document is one of a collection that, together, describe the
15 protocol and usage context for a revision of Internationalized Domain
16 Names for Applications (IDNA), superseding the earlier version. It
17 describes the document collection and provides definitions and other
18 material that are common to the set.
20 Status of this Memo
22 This Internet-Draft is submitted to IETF in full conformance with the
23 provisions of BCP 78 and BCP 79.
25 Internet-Drafts are working documents of the Internet Engineering
26 Task Force (IETF), its areas, and its working groups. Note that
27 other groups may also distribute working documents as Internet-
28 Drafts.
30 Internet-Drafts are draft documents valid for a maximum of six months
31 and may be updated, replaced, or obsoleted by other documents at any
32 time. It is inappropriate to use Internet-Drafts as reference
33 material or to cite them other than as "work in progress."
35 The list of current Internet-Drafts can be accessed at
36 http://www.ietf.org/ietf/1id-abstracts.txt.
38 The list of Internet-Draft Shadow Directories can be accessed at
39 http://www.ietf.org/shadow.html.
41 This Internet-Draft will expire on July 11, 2010.
43 Copyright Notice
45 Copyright (c) 2010 IETF Trust and the persons identified as the
46 document authors. All rights reserved.
48 This document is subject to BCP 78 and the IETF Trust's Legal
49 Provisions Relating to IETF Documents
50 (http://trustee.ietf.org/license-info) in effect on the date of
51 publication of this document. Please review these documents
52 carefully, as they describe your rights and restrictions with respect
53 to this document. Code Components extracted from this document must
54 include Simplified BSD License text as described in Section 4.e of
55 the Trust Legal Provisions and are provided without warranty as
56 described in the BSD License.
58 This document may contain material from IETF Documents or IETF
59 Contributions published or made publicly available before November
60 10, 2008. The person(s) controlling the copyright in some of this
61 material may not have granted the IETF Trust the right to allow
62 modifications of such material outside the IETF Standards Process.
63 Without obtaining an adequate license from the person(s) controlling
64 the copyright in such materials, this document may not be modified
65 outside the IETF Standards Process, and derivative works of it may
66 not be created outside the IETF Standards Process, except to format
67 it for publication as an RFC or to translate it into languages other
68 than English.
70 Table of Contents
72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
73 1.1. IDNA2008 . . . . . . . . . . . . . . . . . . . . . . . . . 4
74 1.1.1. Audiences . . . . . . . . . . . . . . . . . . . . . . 4
75 1.1.2. Normative Language . . . . . . . . . . . . . . . . . . 5
76 1.2. Discussion Forum . . . . . . . . . . . . . . . . . . . . . 5
77 1.3. Roadmap of IDNA2008 Documents . . . . . . . . . . . . . . 5
78 2. Definitions and Terminology . . . . . . . . . . . . . . . . . 6
79 2.1. Characters and Character Sets . . . . . . . . . . . . . . 6
80 2.2. DNS-related Terminology . . . . . . . . . . . . . . . . . 6
81 2.3. Terminology Specific to IDNA . . . . . . . . . . . . . . . 7
82 2.3.1. LDH-label . . . . . . . . . . . . . . . . . . . . . . 7
83 2.3.2. Terms for IDN Label Codings . . . . . . . . . . . . . 11
84 2.3.2.1. IDNA-valid strings, A-label, and U-label . . . . . 11
85 2.3.2.2. NR-LDH-label and Internationalized Label . . . . . 13
86 2.3.2.3. Internationalized Domain Name . . . . . . . . . . 13
87 2.3.2.4. Label Equivalence . . . . . . . . . . . . . . . . 14
88 2.3.2.5. ACE Prefix . . . . . . . . . . . . . . . . . . . . 14
89 2.3.2.6. Domain Name Slot . . . . . . . . . . . . . . . . . 14
90 2.3.3. Order of Characters in Labels . . . . . . . . . . . . 15
91 2.3.4. Punycode is an Algorithm, not a Name or Adjective . . 15
92 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
93 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16
94 4.1. General Issues . . . . . . . . . . . . . . . . . . . . . . 16
95 4.2. U-label Lengths . . . . . . . . . . . . . . . . . . . . . 16
96 4.3. Local Character Set Issues . . . . . . . . . . . . . . . . 17
97 4.4. Visually Similar Characters . . . . . . . . . . . . . . . 17
98 4.5. IDNA Lookup, Registration, and the Base DNS
99 Specifications . . . . . . . . . . . . . . . . . . . . . . 18
100 4.6. Legacy IDN Label Strings . . . . . . . . . . . . . . . . . 18
101 4.7. Security Differences from IDNA2003 . . . . . . . . . . . . 19
102 4.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 19
103 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
104 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
105 6.1. Normative References . . . . . . . . . . . . . . . . . . . 20
106 6.2. Informative References . . . . . . . . . . . . . . . . . . 21
107 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22
108 A.1. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 23
109 A.2. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 23
110 A.3. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 23
111 A.4. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 23
112 A.5. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 23
113 A.6. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 24
114 A.7. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 24
115 A.8. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 24
116 A.9. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 24
117 A.10. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 25
118 A.11. Version -10 . . . . . . . . . . . . . . . . . . . . . . . 25
119 A.12. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 25
120 A.13. Version -12 . . . . . . . . . . . . . . . . . . . . . . . 26
121 A.14. Version -13 . . . . . . . . . . . . . . . . . . . . . . . 26
122 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
124 1. Introduction
126 1.1. IDNA2008
128 This document is one of a collection that, together, describe the
129 protocol and usage context for a revision of Internationalized Domain
130 Names for Applications (IDNA) that was largely completed in 2008,
131 known within the series and elsewhere as IDNA2008. The series
132 replaces an earlier version of IDNA, described in [RFC3490] and
133 [RFC3491]. For convenience, that version of IDNA is referred to in
134 this documents as "IDNA2003". The newer version continues to use the
135 Punycode algorithm [RFC3492] and ACE (ASCII-compatible encoding)
136 prefix from that earlier version. The document collection is
137 described in Section 1.3. As indicated there, this document provides
138 definitions and other material that are common to the set.
140 1.1.1. Audiences
142 While many IETF specifications are directed exclusively to protocol
143 implementers, the character of IDNA requires that it be understood
144 and properly used by those whose responsibilities include making
145 decisions about
147 o what names are permitted in DNS zone files,
149 o policies related to names and naming, and
151 o the handling of domain name strings in files and systems, even
152 with no immediate intention of looking them up.
154 This document and those concerned with the protocol definition, rules
155 for handling strings that include characters written right-to-left,
156 and the actual list of characters and categories will be of primary
157 interest to protocol implementers. This document and the one
158 containing explanatory material will be of primary interest to
159 others, although they may have to fill in some details by reference
160 to other documents in the set.
162 This document and the associated ones are written from the
163 perspective of an IDNA-aware user, application, or implementation.
164 While they may reiterate fundamental DNS rules and requirements for
165 the convenience of the reader, they make no attempt to be
166 comprehensive about DNS principles and should not be considered as a
167 substitute for a thorough understanding of the DNS protocols and
168 specifications.
170 1.1.2. Normative Language
172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
174 document are to be interpreted as described in RFC 2119 [RFC2119].
176 1.2. Discussion Forum
178 [[ RFC Editor: please remove this section. ]]
180 IDNA2008 is being discussed in the IETF "idnabis" Working Group and
181 on the mailing list idna-update@alvestrand.no
183 1.3. Roadmap of IDNA2008 Documents
185 IDNA2008 consists of the following documents:
187 o This document, containing definitions and other material that are
188 needed for understanding other documents in the set. It is
189 referred to informally in other documents in the set as "Defs" or
190 "Definitions".
192 o A document [IDNA2008-Rationale] that provides an overview of the
193 protocol and associated tables together with explanatory material
194 and some rationale for the decisions that led to IDNA2008. That
195 document also contains advice for registry operations and those
196 who use internationalized domain names. It is referred to
197 informally in other documents in the set as "Rationale". It is
198 not normative.
200 o A document [IDNA2008-Protocol] that describes the core IDNA2008
201 protocol and its operations. In combination with the "Bidi"
202 document described immediately below, it explicitly updates and
203 replaces RFC 3490. It is referred to informally in other
204 documents in the set as "Protocol".
206 o A document [IDNA2008-Bidi] that specifies special rules ("Bidi")
207 for labels that contain characters that are written from right to
208 left.
210 o A specification [IDNA2008-Tables] of the categories and rules that
211 identify the code points allowed in a label written in native
212 character form (defined more specifically as a "U-label" in
213 Section 2.3.2.1 below), based on Unicode 5.2 [Unicode52] code
214 point assignments and additional rules unique to IDNA2008. The
215 Unicode-based rules are expected to be stable across Unicode
216 updates and hence independent of Unicode versions. That
217 specification obsoletes RFC 3941 and IDN use of the tables to
218 which it refers. It is referred to informally in other documents
219 in the set as "Tables".
221 o A document [IDNA2008-Mapping] that discusses the issue of mapping
222 characters into other characters and that provides guidance for
223 doing so when that is appropriate. This document provides advice;
224 it is not a required part of IDNA.
226 2. Definitions and Terminology
228 2.1. Characters and Character Sets
230 A code point is an integer value in the codespace of a coded
231 character set. In Unicode, these are integers from 0 to 0x10FFFF.
233 Unicode [Unicode52] is a coded character set with about 100,000
234 characters assigned to code points as of version 5.1. A single
235 Unicode code point is denoted in these documents by "U+" followed by
236 four to six hexadecimal digits, while a range of Unicode code points
237 is denoted by two four to six digit hexadecimal numbers separated by
238 "..", with no prefixes.
240 ASCII means US-ASCII [ASCII], a coded character set containing 128
241 characters associated with code points in the range 0000..007F.
242 Unicode is a superset of ASCII and may be thought of as a
243 generalization of it; it includes all the ASCII characters and
244 associates them with equivalent code points.
246 "Letters" are, informally, generalizations from the ASCII and common-
247 sense understanding of that term, i.e., characters that are used to
248 write text that are not digits, symbols, or punctuation. Formally,
249 they are characters with a Unicode General Category value starting in
250 "L" (see Section 4.5 of [Unicode52]).
252 2.2. DNS-related Terminology
254 When discussing the DNS, this document generally assumes the
255 terminology used in the DNS specifications [RFC1034] [RFC1035] as
256 modified by [RFC1123] and [RFC2181]. The term "lookup" is used to
257 describe the combination of operations performed by the IDNA2008
258 protocol and those actually performed by a DNS resolver. The process
259 of placing an entry into the DNS is referred to as "registration",
260 similar to common contemporary usage in other contexts.
261 Consequently, any DNS zone administration is described as a
262 "registry", and the terms "registry" and "zone administrator" are
263 used interchangeably, regardless of the actual administrative
264 arrangements or level in the DNS tree. More detail about that
265 relationship is included in the "Rationale" document.
267 The term "LDH code point" is defined in this document to refer to the
268 code points associated with ASCII letters (Unicode code points
269 0041..005A and 0061..007A), digits (0030..0039), and the hyphen-minus
270 (U+002D). "LDH" is an abbreviation for "letters, digits, hyphen".
272 The base DNS specifications [RFC1034] [RFC1035] discuss "domain
273 names" and "host names", but many people use the terms
274 interchangeably, as do sections of these specifications. Lack of
275 clarity about that terminology has contributed to confusion about
276 intent in some cases. These documents generally use the term "domain
277 name". When they refer to, e.g., host name syntax restrictions, they
278 explicitly cite the relevant defining documents. The remaining
279 definitions in this subsection are essentially a review: if there is
280 any perceived difference between those definitions and the
281 definitions in the base DNS documents or those cited below, the
282 definitions in the other documents take precedence.
284 A label is an individual component of a domain name. Labels are
285 usually shown separated by dots; for example, the domain name
286 "www.example.com" is composed of three labels: "www", "example", and
287 "com". (The zero-length root label described in RFC 1123 [RFC1123],
288 which can be explicit as in "www.example.com." or implicit as in
289 "www.example.com", is not considered in this specification.) IDNA
290 extends the set of usable characters in labels that are treated as
291 text (as distinct from the binary string labels discussed in RFC 1035
292 and RFC 2181 [RFC2181] and the bitstring ones described in RFC 2673
293 [RFC2673]), but only in certain contexts. The different contexts for
294 different sets of usable characters are outlined in the next section.
295 For the rest of this document and in the related ones, the term
296 "label" is shorthand for "text label", and "every label" means "every
297 text label", including the expanded context.
299 2.3. Terminology Specific to IDNA
301 This section defines some terminology to reduce dependence on terms
302 and definitions that have been problematic in the past. The
303 relationships among these definitions are illustrated in Figure 1 and
304 Figure 2. In the first of those figures, the parenthesized numbers
305 refer to the notes below the figure.
307 2.3.1. LDH-label
309 This is the classical label form used in host names [RFC0952] and
310 described as the preferred form in RFC 1035 [RFC1035]. It is a
311 string consisting of ASCII letters, digits, and the hyphen with the
312 further restriction that the hyphen cannot appear at the beginning or
313 end of the string. Like all DNS labels, its total length must not
314 exceed 63 octets.
316 LDH-labels include the specialized labels used by IDNA (described as
317 "A-labels" below) and some additional restricted forms (also
318 described below).
320 To facilitate clear description, two new subsets of LDH-labels are
321 created by the introduction of IDNA. These are called Reserved LDH
322 labels (R-LDH labels) and Non-Reserved LDH labels (NR-LDH labels).
323 Reserved LDH labels, known as "tagged domain names" in some other
324 contexts, have the property that they contain "--" in the third and
325 fourth characters but which otherwise conform to LDH-label rules.
326 Only a subset of the R-LDH labels can be used in IDNA-aware
327 applications. That subset consists of the class of labels that begin
328 with the prefix "xn--" (case independent), but otherwise conform to
329 the LDH-label rules. That subset is called "XN-labels" in this set
330 of documents. XN-labels are further divided into those whose
331 remaining characters (after the "xn--") are valid output of the
332 Punycode algorithm RFC 3492 [RFC3492] and those that are not (see
333 below). The XN-labels that are valid Punycode output are known as
334 "A-labels" if they also meet the other criteria for IDNA-validity
335 described below. Because LDH-labels (and, indeed, any DNS label)
336 must not be more than 63 octets in length, the Punycode-algorithm-
337 derived portion of XN-labels is limited to no more than 59 ASCII
338 characters. Non-reserved LDH labels are the set of valid LDH labels
339 that do not have "--" in the third and fourth positions.
341 A consequence of the restrictions on valid characters in the native
342 Unicode character form (see U-labels) turns out to be that mixed-case
343 annotation, of the sort outlined in RFC 3492 Appendix A [RFC3492], is
344 never useful. Therefore, since a valid A-label is the result of
345 Punycode encoding of a U-label, A-labels should be produced only in
346 lower case, despite matching other (mixed- or upper-case) potential
347 labels in the DNS.
349 Some labels that are prefixed with "xn--" may not be the output of
350 the Punycode algorithm, or may fail the other tests outlined below or
351 violate other IDNA restrictions and thus are also not valid IDNA-
352 labels. They are called "Fake A-Labels" for convenience.
354 Labels within the class of R-LDH labels that are not prefixed with
355 "xn--" are also not valid IDNA-labels. To allow for future use of
356 mechanisms similar to IDNA, those labels MUST NOT be processed as
357 ordinary LDH-labels by IDNA-conforming programs and SHOULD NOT be
358 mixed with IDNA-labels in the same zone.
360 These distinctions among possible LDH labels are only of significance
361 for software that is "IDNA-aware" or for future extensions that use
362 extensions based on the same "prefix and encoding" model. For IDNA-
363 aware systems, the valid label types are: A-labels, U-labels and NR-
364 LDH labels.
366 IDNA-labels come in two flavors: An ACE-encoded form and a Unicode
367 (native character) form. These are referred to as A-labels and
368 U-labels respectively and are described in detail in the next
369 section.
371 ASCII-LABEL
372 __________________________________________________________________
373 | LDH-LABEL (1) (4) |
374 | _______________________________________________________ |
375 | | ___________________________________ | |
376 | | |IDN Reserved LDH Labels | | |
377 | | | ("??--") or R-LDH LABELS | _______________ | |
378 | | | _______________________________ | |NON-RESERVED | | |
379 | | | | XN LABELS | | | LDH LABELS | | |
380 | | | | _____________ ___________ | | | (NR-LDH | | |
381 | | | | | A-labels | | Fake (3) || | | LABELS) | | |
382 | | | | | "xn--"(2) | | A-labels || | |_____________| | |
383 | | | | |___________| |__________|| | | |
384 | | | |_____________________________| | | |
385 | | |_________________________________| | |
386 | |_______________________________________________________| |
387 | |
388 | _____________NON-LDH-LABEL________ |
389 | | ______________________ | |
390 | | | Underscore labels | | |
391 | | | e.g. _tcp | | |
392 | | |____________________| | |
393 | | | Labels with leading| | |
394 | | | or trailing | | |
395 | | | hyphens "-abcd" | | |
396 | | | or "xyz-" | | |
397 | | | or "-uvw-" | | |
398 | | |____________________| | |
399 | | | Labels with other | | |
400 | | | non-LDH ASCII chars| | |
401 | | | e.g. #$%_ | | |
402 | | |____________________| | |
403 | |________________________________| |
404 |________________________________________________________________|
406 (1) ASCII letters (upper and lower case), digits,
407 hyphen. Hyphen may not appear in first or last
408 position. No more than 63 octets.
409 (2) Note that the string following "xn--" must
410 be the valid output of the Punycode algorithm
411 and must be convertible into valid U-label form.
412 (3) Note that a Fake A-Label has a prefix "xn--"
413 but the remainder of the label is NOT the valid
414 output of the Punycode algorithm.
415 (4) LDH-LABEL subtypes are indistinguishable to
416 IDNA-unaware applications.
418 Figure 1: IDNA and Related DNS Terminology Space -- ASCII labels
419 __________________________
420 | Non-ASCII |
421 | |
422 | ___________________ |
423 | | U-label (5) | |
424 | |_________________| |
425 | | | |
426 | | Binary Label | |
427 | | (including | |
428 | | high bit on) | |
429 | |_________________| |
430 | | | |
431 | | Bit String | |
432 | | Label | |
433 | |_________________| |
434 |________________________|
436 (5) To IDNA-unaware applications, U-labels are
437 indistinguishable from Binary ones.
439 Figure 2: Non-ASCII labels
441 2.3.2. Terms for IDN Label Codings
443 2.3.2.1. IDNA-valid strings, A-label, and U-label
445 For IDNA-aware applications, the three types of valid labels are
446 "A-labels", "U-labels", and "NR-LDH-labels", each of which is defined
447 below. The relationships among them are illustrated in Figure 1 and
448 Figure 2.
450 o A string is "IDNA-valid" if it meets all of the requirements of
451 these specifications for an IDNA label. IDNA-valid strings may
452 appear in either of the two forms, defined immediately below, or
453 may be drawn from the NR-LDH-label subset. IDNA-valid strings
454 must also conform to all basic DNS requirements for labels. These
455 documents make specific reference to the form appropriate to any
456 context in which the distinction is important.
458 o An "A-label" is the ASCII-Compatible Encoding (ACE, see
459 Section 2.3.2.5) form of an IDNA-valid string. It must be a
460 complete label: IDNA is defined for labels, not for parts of them
461 and not for complete domain names. This means, by definition,
462 that every A-label will begin with the IDNA ACE prefix, "xn--"
463 (see Section 2.3.2.5), followed by a string that is a valid output
464 of the Punycode algorithm [RFC3492] and hence a maximum of 59
465 ASCII characters in length. The prefix and string together must
466 conform to all requirements for a label that can be stored in the
467 DNS including conformance to the rules for the preferred form
468 described in RFC 1034, RFC 1035, and RFC 1123. If and only if a
469 string meeting the above requirements can be decoded into a
470 U-label, then it is an A-label.
472 o A "U-label" is an IDNA-valid string of Unicode characters, in
473 normalization form NFC and including at least one non-ASCII
474 character, expressed in a standard Unicode Encoding Form (such as
475 UTF-8). It is also subject to the constraints about permitted
476 characters that are specified in Section 4.2 of the Protocol
477 document and the rules in the Sections 2 and 3 of the Tables
478 document, the Bidi constraints in that document if it contains any
479 character from scripts that are written right to left, and the
480 symmetry constraint described immediately below. Conversions
481 between U-labels and A-labels are performed according to the
482 "Punycode" specification [RFC3492], adding or removing the ACE
483 prefix as needed.
485 To be valid, U-labels and A-labels must obey an important symmetry
486 constraint. While that constraint may be tested in any of several
487 ways, an A-label A1 must be capable of being produced by conversion
488 from a U-label U1, and that U-label U1 must be capable of being
489 produced by conversion from A-label A1. Among other things, this
490 implies that both U-labels and A-labels must be strings in Unicode
491 NFC [Unicode-UAX15] normalized form. These strings MUST contain only
492 characters specified elsewhere in this document series, and only in
493 the contexts indicated as appropriate.
495 Any rules or conventions that apply to DNS labels in general, apply
496 to whichever of the U-label or A-label would be more restrictive.
497 There are two exceptions to this principle. First, the restriction
498 to ASCII characters does not apply to the U-label. Second, expansion
499 of the A-label form to a U-label may produce strings that are much
500 longer than the normal 63 octet DNS limit (potentially up to 252
501 characters) due to the compression efficiency of the Punycode
502 algorithm. Such extended-length U-labels are valid from the
503 standpoint of IDNA, but caution should be exercised as shorter limits
504 may be imposed by some applications.
506 For context, IDNA-unaware applications treat all LDH-labels as valid
507 for appearance in DNS zone files and queries. IDNA-aware
508 applications permit only A-labels and NR-LDH-labels to appear in zone
509 files and queries. U-labels can appear, along with the other two, in
510 presentation and user interface forms, and in protocols that use IDNA
511 forms but that do not involve the DNS itself.
513 Specifically, for IDNA-aware applications, the three allowed
514 categories are A-label, U-label, and NR-LDH-label. Of the reserved
515 LDH labels (R-LDH-labels) only A-labels are valid for IDNA use.
517 Strings that appear to be A-labels or U-labels are processed in
518 various of the operations of [IDNA2008-Protocol]. Those strings are
519 not yet demonstrably conformant with the conditions outlined above,
520 because they are in the process of validation. Such strings may be
521 referred to as "unvalidated", "putative", or "apparent", or as being
522 "in the form of" one of the label types to indicate that they have
523 not been verified to meet the specified conformance requirements.
525 Unvalidated A-labels are known only to be XN-Labels, while Fake
526 A-labels have been demonstrated to fail some of the A-label tests.
527 Similarly, unvalidated U-labels are simply Non-ASCII labels that may
528 or may not meet the requirements for U-labels.
530 2.3.2.2. NR-LDH-label and Internationalized Label
532 These specifications use the term "NR-LDH-label" strictly to refer to
533 an all-ASCII label that obeys the preferred syntax (often known as
534 "hostname" (from RFC 952 [RFC0952]) or "LDH") conventions and that is
535 neither an IDN nor a label form reserved by IDNA (R-LDH-label). It
536 should be stressed that an A-label obeys the "hostname" rules and is
537 sometimes described as "LDH-conformant".
539 2.3.2.3. Internationalized Domain Name
541 An "internationalized domain name" (IDN) is a domain name that
542 contains at least one A-label or U-label, but that otherwise may
543 contain any mixture of NR-LDH-labels, A-labels, or U-labels. Just as
544 has been the case with ASCII names, some DNS zone administrators may
545 impose restrictions, beyond those imposed by DNS or IDNA, on the
546 characters or strings that may be registered as labels in their
547 zones. Because of the diversity of characters that can be used in a
548 U-label and the confusion they might cause, such restrictions are
549 mandatory for IDN registries and zones even though the particular
550 restrictions are not part of these specifications (the issue is
551 discussed in more detail in Section 4.3 of [IDNA2008-Protocol] .
552 Because these restrictions, commonly known as "registry
553 restrictions", only affect what can be registered and not lookup
554 processing, they have no effect on the syntax or semantics of DNS
555 protocol messages; a query for a name that matches no records will
556 yield the same response regardless of the reason why it is not in the
557 zone. Clients issuing queries or interpreting responses cannot be
558 assumed to have any knowledge of zone-specific restrictions or
559 conventions. See the section on registration policy in
560 [IDNA2008-Rationale] for additional discussion.
562 "Internationalized label" is used when a term is needed to refer to a
563 single label of an IDN, i.e., one that might be any of an NR-LDH-
564 label, A-label, or U-label. There are some standardized DNS label
565 formats, such as the "underscore labels" used for service location
566 (SRV) records [RFC2782], that do not fall into any of the three
567 categories and hence are not internationalized labels.
569 2.3.2.4. Label Equivalence
571 In IDNA, equivalence of labels is defined in terms of the A-labels.
572 If the A-labels are equal in a case-independent comparison, then the
573 labels are considered equivalent, no matter how they are represented.
574 Because of the isomorphism of A-labels and U-labels in IDNA2008, it
575 is possible to compare U-labels directly; see [IDNA2008-Protocol] for
576 details. Traditional LDH labels already have a notion of
577 equivalence: within that list of characters, upper case and lower
578 case are considered equivalent. The IDNA notion of equivalence is an
579 extension of that older notion but, because the protocol does not
580 specify any mandatory mapping and only those isomorphic forms are
581 considered, the only equivalents are:
583 o Exact (bit-string identity) matches between a pair of U-labels.
585 o Matches between a pair of A-labels, using normal DNS matching
586 rules.
588 o Equivalence between a U-label and an A-label determined by
589 translating the U-label form into an A-label form and then testing
590 for a match between the A-labels using normal DNS case-insensitive
591 matching rules.
593 2.3.2.5. ACE Prefix
595 The "ACE prefix" is defined in this document to be a string of ASCII
596 characters "xn--" that appears at the beginning of every A-label.
597 "ACE" stands for "ASCII-Compatible Encoding".
599 2.3.2.6. Domain Name Slot
601 A "domain name slot" is defined in this document to be a protocol
602 element or a function argument or a return value (and so on)
603 explicitly designated for carrying a domain name. Examples of domain
604 name slots include the QNAME field of a DNS query; the name argument
605 of the gethostbyname() or getaddrinfo() standard C library functions;
606 the part of an email address following the at-sign (@) in the
607 parameter to the SMTP MAIL or RCPT commands or the "From:" field of
608 an email message header; and the host portion of the URI in the src
609 attribute of an HTML tag. A string that has the syntax of a
610 domain name but that appears in general text is not in a domain name
611 slot. For example, a domain name appearing in the plain text body of
612 an email message is not occupying a domain name slot.
614 An "IDN-aware domain name slot" is defined for this set of documents
615 to be a domain name slot explicitly designated for carrying an
616 internationalized domain name as defined in this document. The
617 designation may be static (for example, in the specification of the
618 protocol or interface) or dynamic (for example, as a result of
619 negotiation in an interactive session).
621 An "IDN-unaware domain name slot" is defined for this set of
622 documents to be any domain name slot that is not an IDN-aware domain
623 name slot. Obviously, this includes any domain name slot whose
624 specification predates IDNA. Note that the requirements of some
625 protocols that use the DNS for data storage prevent the use of IDNs.
626 For example, the format required for the underscore labels used by
627 the service location protocol [RFC2782] precludes representation of a
628 non-ASCII label in the DNS using A-labels because those SRV-related
629 labels must start with underscores. Of course, non-ASCII IDN labels
630 may be part of a domain name that also includes underscore labels.
632 2.3.3. Order of Characters in Labels
634 Because IDN labels may contain characters that are read, and
635 preferentially displayed, from right to left, there is a potential
636 ambiguity about which character in a label is "first". For the
637 purposes of these specifications, labels are considered, and
638 characters numbered, strictly in the order in which they appear "on
639 the wire". That order is equivalent to the leftmost character being
640 treated as first in a label that is read left-to-right and to the
641 rightmost character being first in a label that is read right-to-
642 left. The "Bidi" specification contains additional discussion of the
643 conditions that influence reading order.
645 2.3.4. Punycode is an Algorithm, not a Name or Adjective
647 There has been some confusion about whether a "Punycode string" does
648 or does not include the ACE prefix and about whether it is required
649 that such strings could have been the output of the ToASCII operation
650 (see RFC 3490, Section 4 [RFC3490]). This specification discourages
651 the use of the term "Punycode" to describe anything but the encoding
652 method and algorithm of [RFC3492]. The terms defined above are
653 preferred as much more clear than the term "Punycode string".
655 3. IANA Considerations
657 Actions for IANA are specified in other documents in this series
659 [IDNA2008-Protocol] [IDNA2008-Tables]. An overview of the
660 relationships among the various IANA registries appears in
661 [IDNA2008-Rationale]. This document does not specify any actions for
662 IANA.
664 4. Security Considerations
666 4.1. General Issues
668 Security on the Internet partly relies on the DNS. Thus, any change
669 to the characteristics of the DNS can change the security of much of
670 the Internet.
672 Domain names are used by users to identify and connect to Internet
673 hosts and other network resources. The security of the Internet is
674 compromised if a user entering a single internationalized name is
675 connected to different servers based on different interpretations of
676 the internationalized domain name. In addition to characters that
677 are permitted by IDNA2003 and its mapping conventions (See
678 Section 4.6), the current specification changes the interpretation of
679 a few characters that were mapped to others in the earlier version;
680 zone administrators should be aware of the problems that might raise
681 and take appropriate measures. The context for this issue is
682 discussed in more detail in [IDNA2008-Rationale]).
684 In addition to the Security Considerations material that appears in
685 this document, [IDNA2008-Bidi] contains a discussion of security
686 issues specific to labels containing characters from scripts that are
687 normally written right to left.
689 4.2. U-label Lengths
691 Labels associated with the DNS have traditionally been limited to 63
692 octets by the general restrictions in RFC 1035 and by the need to
693 treat them as a six-bit string length followed by the string in
694 actual calls to the DNS. That format is used in some other
695 applications and, in general, that representations of domain names as
696 dot-separated labels and as length-string pair have been treated as
697 interchangeable. Because A-labels (the form actually used in the
698 DNS) are potentially much more compressed than UTF-8 (and UTF-8 is,
699 in general, more compressed that UTF-16 or UTF-32), U-labels that
700 obey all of the relevant symmetry (and other) constraints of these
701 documents may be quite a bit longer, potentially up to 252 characters
702 (Unicode code points). A fully-qualified domain name containing
703 several such labels can obviously also exceed the nominal 255 octet
704 limit for such names. Application authors using U-labels must exert
705 due caution to avoid buffer overflow and truncation errors and
706 attacks in contexts where shorter strings are expected.
708 4.3. Local Character Set Issues
710 When systems use local character sets other than ASCII and Unicode,
711 these specifications leave the problem of converting between the
712 local character set and Unicode up to the application or local
713 system. If different applications (or different versions of one
714 application) implement different rules for conversions among coded
715 character sets, they could interpret the same name differently and
716 contact different servers. This problem is not solved by security
717 protocols, such as Transport Layer Security (TLS) [RFC5246], that do
718 not take local character sets into account.
720 4.4. Visually Similar Characters
722 To help prevent confusion between characters that are visually
723 similar (sometimes called "confusables"), it is suggested that
724 implementations provide visual indications where a domain name
725 contains multiple scripts, especially when the scripts contain
726 characters that are easily confused visually, such as an omicron in
727 Greek mixed with Latin text. Such mechanisms can also be used to
728 show when a name contains a mixture of simplified and traditional
729 Chinese characters, or to distinguish zero and one from upper-case
730 "O" and lower-case "L". DNS zone administrators may impose
731 restrictions (subject to the limitations identified elsewhere in
732 these documents) that try to minimize characters that have similar
733 appearance or similar interpretations.
735 If multiple characters appear in a label and the label consists only
736 of characters in one script, individual characters that might be
737 confused with others if compared separately may be unambiguous and
738 non-confusing. On the other hand, that observation makes mixed-
739 script labels even more risky -- users will tend to see what they
740 expect to see and context is a powerful reinforcement to perception.
741 At the same time, while the risks associated with mixed-script labels
742 are clear, simply prohibiting them will not eliminate problems,
743 especially where closely-related scripts are involved. For example,
744 there are many strings that are entirely in Greek or Cyrillic scripts
745 that can be confused with each other or with Latin-script strings.
747 It is worth noting that there are no comprehensive technical
748 solutions to the problems of confusable characters. One can reduce
749 the extent of the problems in various ways, but probably never
750 eliminate it. Some specific suggestions about identification and
751 handling of confusable characters appear in a Unicode Consortium
752 publication [Unicode-UTR36].
754 4.5. IDNA Lookup, Registration, and the Base DNS Specifications
756 The Protocol specification [IDNA2008-Protocol] describes procedures
757 for registering and looking up labels that are not compatible with
758 the preferred syntax described in the base DNS specifications (STD13
759 [RFC1034] [RFC1035] and Host Requirements [RFC1123]) because they
760 contain non-ASCII characters. These procedures depend on the use of
761 a special ASCII-compatible encoding form that contains only
762 characters permitted in host names by those earlier specifications.
763 The encoding used is Punycode [RFC3492]. No security issues such as
764 string length increases or new allowed values are introduced by the
765 encoding process or the use of these encoded values, apart from those
766 introduced by the ACE encoding itself.
768 Domain names (or portions of them) are sometimes compared against a
769 set of domains to be given special treatment if a match occurs, e.g.,
770 treated as more privileged than others or blocked in some way. In
771 such situations, it is especially important that the comparisons be
772 done properly, as specified in the Requirements section of
773 [IDNA2008-Protocol]. For labels already in ASCII form, the proper
774 comparison reduces to the same case-insensitive ASCII comparison that
775 has always been used for ASCII labels although IDNA-aware
776 applications are expected to look up only A-labels and NR-LDH-labels,
777 i.e., to avoid looking up R-LDH-labels that are not A-labels.
779 The introduction of IDNA meant that any existing labels that start
780 with the ACE prefix would be construed as A-labels, at least until
781 they failed one of the relevant tests, whether or not that was the
782 intent of the zone administrator or registrant. There is no evidence
783 that this has caused any practical problems since RFC 3490 was
784 adopted, but the risk still exists in principle.
786 4.6. Legacy IDN Label Strings
788 The URI Standard [RFC3986] and a number of application specifications
789 (e.g., [RFC5321], [RFC2616]) do not permit non-ASCII labels in DNS
790 names used with those protocols, i.e., only the A-label form of IDNs
791 is permitted in those contexts. If only A-labels are used,
792 differences in interpretation between IDNA2003 and this version arise
793 only for characters whose interpretation have actually changed (e.g.,
794 characters, such as ZWJ and ZWNJ, that were mapped to nothing in
795 IDNA2003 and that are considered legitimate in some contexts by these
796 specifications). Despite that prohibition, there are a significant
797 number of files and databases on the Internet in which domain name
798 strings appear in native-character form; a subset of those strings
799 use native-character labels that require IDNA2003 mapping to produce
800 valid A-labels. The treatment of such labels will vary by types of
801 applications and application-designer preference: in some situations,
802 warnings to the user or outright rejection may be appropriate; in
803 others, it may be preferable to attempt to apply the earlier mappings
804 if lookup strictly conformant to these specifications fails or even
805 to do lookups under both sets of rules. This general situation is
806 discussed in more detail in [IDNA2008-Rationale]. However, in the
807 absence of care by registries about how strings that could have
808 different interpretations under IDNA2003 and the current
809 specification are handled, it is possible that the differences could
810 be used as a component of name-matching or name-confusion attacks.
811 Such care is therefore appropriate.
813 4.7. Security Differences from IDNA2003
815 The registration and lookup models described in this set of documents
816 change the mechanisms available for lookup applications to determine
817 the validity of labels they encounter. In some respects, the ability
818 to test is strengthened. For example, putative labels that contain
819 unassigned code points will now be rejected, while IDNA2003 permitted
820 them (see [IDNA2008-Rationale] for a discussion of the reasons for
821 this). On the other hand, the protocol specification no longer
822 assumes that the application that looks up a name will be able to
823 determine, and apply, information about the protocol version used in
824 registration. In theory, that may increase risk since the
825 application will be able to do less pre-lookup validation. In
826 practice, the protection afforded by that test has been largely
827 illusory for reasons explained in RFC 4690 [RFC4690] and elsewhere in
828 these documents.
830 Any change to the Stringprep [RFC3454] procedure that is profiled and
831 used in IDNA2003, or, more broadly, the IETF's model of the use of
832 internationalized character strings in different protocols, creates
833 some risk of inadvertent changes to those protocols, invalidating
834 deployed applications or databases, and so on. But these
835 specifications do not change Stringprep at all; they merely bypass
836 it. Because these documents do not depend on Stringprep, the
837 question of upgrading other protocols that do have that dependency
838 can be left to experts on those protocols: the IDNA changes and
839 possible upgrades to security protocols or conventions are
840 independent issues.
842 4.8. Summary
844 No mechanism involving names or identifiers alone can protect against
845 a wide variety of security threats and attacks that are largely
846 independent of the naming or identification system. These attacks
847 include spoofed pages, DNS query trapping and diversion, and so on.
849 5. Acknowledgments
851 The initial version of this document was created largely by
852 extracting text from the "rationale" document [IDNA2008-Rationale].
853 See the section of this name, and the one entitled "Contributors", in
854 it.
856 Specific textual suggestions after the extraction process came from
857 Vint Cerf, Lisa Dusseault, Bill McQuillan, Andrew Sullivan, and Ken
858 Whistler. Other changes were made in response to more general
859 comments, lists of concerns or specific errors from participants in
860 the Working Group and other observers, including Lyman Chapin, James
861 Mitchell, Subramanian Moonesamy, and Dan Winship.
863 6. References
865 6.1. Normative References
867 [ASCII] American National Standards Institute (formerly United
868 States of America Standards Institute), "USA Code for
869 Information Interchange", ANSI X3.4-1968, 1968.
871 ANSI X3.4-1968 has been replaced by newer versions with
872 slight modifications, but the 1968 version remains
873 definitive for the Internet.
875 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
876 STD 13, RFC 1034, November 1987.
878 [RFC1035] Mockapetris, P., "Domain names - implementation and
879 specification", STD 13, RFC 1035, November 1987.
881 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
882 and Support", STD 3, RFC 1123, October 1989.
884 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
885 Requirement Levels", BCP 14, RFC 2119, March 1997.
887 [Unicode-UAX15]
888 The Unicode Consortium, "Unicode Standard Annex #15:
889 Unicode Normalization Forms", March 2008,
890 .
892 [Unicode52]
893 The Unicode Consortium, "The Unicode Standard, Version
894 5.2.0", 2009.
896 defined by: The Unicode Standard, Version 5.0, Boston, MA,
897 Addison-Wesley, 2007, ISBN 0-321-48091-0, as amended by
898 Unicode 5.1.0 (2008)
899 (http://www.unicode.org/versions/Unicode5.1.0/) and
900 Unicode 5.2.0 (2009)
901 (http://www.unicode.org/versions/Unicode5.2.0/).
903 6.2. Informative References
905 [IDNA2008-Bidi]
906 Alvestrand, H. and C. Karp, "An updated IDNA criterion for
907 right to left scripts", August 2009, .
910 [IDNA2008-Mapping]
911 Resnick, P. and P. Hoffman, "Mapping Characters in IDNA",
912 September 2009, .
915 [IDNA2008-Protocol]
916 Klensin, J., "Internationalized Domain Names in
917 Applications (IDNA): Protocol", September 2009, .
920 [IDNA2008-Rationale]
921 Klensin, J., "Internationalized Domain Names for
922 Applications (IDNA): Background, Explanation, and
923 Rationale", August 2009, .
926 [IDNA2008-Tables]
927 Faltstrom, P., "The Unicode Code Points and IDNA",
928 August 2009, .
931 A version of this document is available in HTML format at
932 http://stupid.domain.name/idnabis/
933 draft-ietf-idnabis-tables-02.html
935 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
936 host table specification", RFC 952, October 1985.
938 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
939 Specification", RFC 2181, July 1997.
941 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
942 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
943 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
945 [RFC2673] Crawford, M., "Binary Labels in the Domain Name System",
946 RFC 2673, August 1999.
948 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
949 specifying the location of services (DNS SRV)", RFC 2782,
950 February 2000.
952 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
953 Internationalized Strings ("stringprep")", RFC 3454,
954 December 2002.
956 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
957 "Internationalizing Domain Names in Applications (IDNA)",
958 RFC 3490, March 2003.
960 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
961 Profile for Internationalized Domain Names (IDN)",
962 RFC 3491, March 2003.
964 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
965 for Internationalized Domain Names in Applications
966 (IDNA)", RFC 3492, March 2003.
968 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
969 Resource Identifier (URI): Generic Syntax", STD 66,
970 RFC 3986, January 2005.
972 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and
973 Recommendations for Internationalized Domain Names
974 (IDNs)", RFC 4690, September 2006.
976 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
977 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
979 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
980 October 2008.
982 [Unicode-UTR36]
983 The Unicode Consortium, "Unicode Technical Report #36:
984 Unicode Security Considerations", July 2008,
985 .
987 Appendix A. Change Log
989 [[RFC Editor: Please remove this appendix]]
991 A.1. Version -00
993 This document was created by pulling selected material out of
994 draft-ietf-idnabis-rationale-03 ("Rationale") after a WG consensus
995 call indicated that the rearrangement was appropriate. Mark Davis
996 made the major contribution of getting the process started by
997 identifying particular sections to be moved, even though this draft
998 does not completely reflect his list.
1000 For Version -00 only, each section is identified with the associated
1001 former section of Rationale-03. Those sections were edited after
1002 incorporation into this document, so "Formerly" should be interpreted
1003 very loosely.
1005 A.2. Version -01
1007 o Typographical errors corrected and some sections slightly renamed
1008 for clarity.
1010 o Other adjustments made to synchronize with current versions of
1011 "Rationale" and "Protocol".
1013 A.3. Version -02
1015 o All back pointers to section numbers in Rationale have been
1016 removed.
1018 o Some definitions clarified. Added one about string order.
1020 o Usual small editorial tuning.
1022 A.4. Version -03
1024 o Additional fine tuning based on discussions during and immediately
1025 before IETF 72.
1027 A.5. Version -04
1029 o Corrections of text and improvement of definitions based on
1030 discussions after -03 was released.
1032 o Discussion of label comparisons tightened and made more consistent
1033 with Protocol.
1035 o Definitions of categories of labels supplemented with a picture
1036 (Figure 1).
1038 o Explicit text added to define strings that look like A-labels or
1039 U-labels but are not. This section was the original Section 2.3.3
1040 which was then removed due to another rewrite (See Appendix A.11).
1042 A.6. Version -05
1044 o Consolidated Security Considerations sections, moving material
1045 from Protocol and Rationale here.
1047 A.7. Version -06
1049 o Added pointer to the discussion, in Rationale, of looking up
1050 unassigned code points.
1052 o Clarified relationship to base DNS specifications.
1054 o Made several clarifications suggested by Mark Davis.
1056 o Added a security considerations stub to more explicitly mention
1057 issues with IDNA2003 labels (Section 4.6).
1059 o Rewrote definitions and terminology using suggestions (and
1060 considerable text and revised figures) from Vint Cerf. Relocated
1061 the figures for easier accessibility.
1063 o Small editorial corrections and new copyright material.
1065 A.8. Version -07
1067 o Modified Figure 1 to put an additional box around NR-LDH Labels
1068 (per Andrew Sullivan) and rationalized spelling of "non-reserved".
1070 o Added a temporary note about page breaks and the figures.
1072 o Modified terminology slightly to mention "underscore labels" and
1073 to revise the statements about equivalence.
1075 A.9. Version -08
1077 o Corrected several typos, at least one of them confusing (NR-LDH-
1078 Label instead or R-LDH-Label).
1080 o Added new text to the discussion of U-labels and A-labels (end of
1081 Section 2.3.2.1) to support the text in Protocol about not-yet-
1082 validated strings. See the note there.
1084 A.10. Version -09
1086 o Added a pointer to the Mapping document.
1088 o Updated references to other documents.
1090 A.11. Version -10
1092 o Updated references to other documents.
1094 o Corrected several issues pointed out by Andrew Sullivan, including
1095 editorial problems.
1097 o Former Section 2.3.3 removed as redundant with Section 2.3.2.1,
1098 which has been rewritten somewhat for clarity.
1100 o Remove placeholders/ requests for further clarification because
1101 there have been no suggestions.
1103 o Adjusted definition of "IDN".
1105 o Note: No further changes made or required for mapping other than
1106 an update to the references and removal of a placeholder that
1107 turned out to be unnecessary.
1109 o Note: Corrections and improvements to figure formatting and
1110 insertion of section numbers have been deferred to the post-WG-LC
1111 version. I only want to do that once.
1113 A.12. Version -11
1115 o Added new material to Section 4.4 on visually similar characters
1116 and contexts.
1118 o Added definition for "IDNA2003".
1120 o Reformatted Figure 1 again.
1122 o Adjusted Acknowledgments to remove Mark Davis's name, per his
1123 request and advice from IETF Trust Counsel.
1125 o Adjusted description of 63 character limit on labels and added
1126 Security Consideration material on that subject.
1128 o Incorporated other changes from WG Last Call, including a note
1129 about upper case A-labels.
1131 o Several small editorial changes.
1133 o Inserted section numbers in references to other IDNA2008
1134 documents.
1136 A.13. Version -12
1138 This is the version of the document produced to reflect comments on
1139 IETF Last Call. For the convenience of those who made comments and
1140 of the IESG in evaluating them, this section therefore identifies
1141 non-editorial changes made in response to Last Call comments in
1142 somewhat more detail than may be usual.
1144 o DNS length limit clarified to be in octets, not "characters"
1145 (whatever those are) in several places. (SM review, 20091011)
1147 o Clarify relationship between label equivalence and mapping. (SM
1148 review, 20091011)
1150 o Corrected accidently-dropped text in A-label definition. (Dan
1151 Winship, note of 20091013)
1153 o Made another round of patches to the case-sensitivity of A-labels.
1154 (James Mitchell, 20091014)
1156 o Removed the "selected protocols" handwaving from Section 2.3.2.1.
1157 (Peter Saint-Andre, 20091019)
1159 o Some minor corrections requested by Suresh Krishnan in the Gen-ART
1160 review of 20091016.
1162 A.14. Version -13
1164 Version incorporating IESG post-Last-Call review and evaluation
1165 comments.
1167 o Editorial and reference corrections, including bringing Unicode
1168 reference to 5.2.
1170 Author's Address
1172 John C Klensin
1173 1770 Massachusetts Ave, Ste 322
1174 Cambridge, MA 02140
1175 USA
1177 Phone: +1 617 245 1457
1178 Email: john+ietf@jck.com