idnits 2.17.1
draft-ietf-idnabis-defs-05.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 17.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 835.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 846.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 853.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 859.
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 Copyright Line does not match the
current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (December 11, 2008) is 5616 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. 'Unicode51'
-- 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 (==), 16 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. Klensin
3 Internet-Draft December 11, 2008
4 Obsoletes: 3490 (if approved)
5 Intended status: Standards Track
6 Expires: June 14, 2009
8 Internationalized Domain Names for Applications (IDNA): Definitions and
9 Document Framework
10 draft-ietf-idnabis-defs-05.txt
12 Status of this Memo
14 By submitting this Internet-Draft, each author represents that any
15 applicable patent or other IPR claims of which he or she is aware
16 have been or will be disclosed, and any of which he or she becomes
17 aware will be disclosed, in accordance with Section 6 of BCP 79.
19 Internet-Drafts are working documents of the Internet Engineering
20 Task Force (IETF), its areas, and its working groups. Note that
21 other groups may also distribute working documents as Internet-
22 Drafts.
24 Internet-Drafts are draft documents valid for a maximum of six months
25 and may be updated, replaced, or obsoleted by other documents at any
26 time. It is inappropriate to use Internet-Drafts as reference
27 material or to cite them other than as "work in progress."
29 The list of current Internet-Drafts can be accessed at
30 http://www.ietf.org/ietf/1id-abstracts.txt.
32 The list of Internet-Draft Shadow Directories can be accessed at
33 http://www.ietf.org/shadow.html.
35 This Internet-Draft will expire on June 14, 2009.
37 Abstract
39 This document is one of a collection that, together, describe the
40 protocol and usage context for a revision of Internationalized Domain
41 Names for Applications (IDNA), superseding the earlier version. It
42 describes the document collection and provides definitions and other
43 material that are common to the set.
45 Table of Contents
47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
48 1.1. IDNA2008 . . . . . . . . . . . . . . . . . . . . . . . . . 3
49 1.1.1. Audiences . . . . . . . . . . . . . . . . . . . . . . 3
50 1.1.2. Normative Language . . . . . . . . . . . . . . . . . . 3
51 1.2. Discussion Forum . . . . . . . . . . . . . . . . . . . . . 3
52 1.3. Roadmap of IDNA2008 Documents . . . . . . . . . . . . . . 4
53 2. Definitions and Terminology . . . . . . . . . . . . . . . . . 4
54 2.1. Characters and Character Sets . . . . . . . . . . . . . . 4
55 2.2. DNS-related Terminology . . . . . . . . . . . . . . . . . 5
56 2.3. Terminology Specific to IDNA . . . . . . . . . . . . . . . 6
57 2.3.1. Terms for IDN Label Codings . . . . . . . . . . . . . 6
58 2.3.1.1. IDNA-valid strings, A-label, and U-label . . . . . 6
59 2.3.1.2. LDH-label and Internationalized Label . . . . . . 8
60 2.3.1.3. Internationalized Domain Name . . . . . . . . . . 8
61 2.3.1.4. Label Equivalence . . . . . . . . . . . . . . . . 8
62 2.3.1.5. ACE Prefix . . . . . . . . . . . . . . . . . . . . 9
63 2.3.1.6. Domain Name Slot . . . . . . . . . . . . . . . . . 9
64 2.3.2. Strings Proposed to be Used or Looked Up as Labels . . 11
65 2.3.3. Order of Characters in Labels . . . . . . . . . . . . 11
66 2.3.4. Punycode is an Algorithm, not a Name or Adjective . . 11
67 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
69 4.1. General Issues . . . . . . . . . . . . . . . . . . . . . . 12
70 4.2. Local Character Set Issues . . . . . . . . . . . . . . . . 12
71 4.3. Visually Similar Characters . . . . . . . . . . . . . . . 12
72 4.4. IDNA Lookup, Registration, and the Base DNS
73 Specifications . . . . . . . . . . . . . . . . . . . . . . 13
74 4.5. Security Differences from IDNA2003 . . . . . . . . . . . . 13
75 4.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 14
76 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
78 6.1. Normative References . . . . . . . . . . . . . . . . . . . 15
79 6.2. Informative References . . . . . . . . . . . . . . . . . . 15
80 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17
81 A.1. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 17
82 A.2. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 17
83 A.3. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 17
84 A.4. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 18
85 A.5. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 18
86 A.6. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 18
87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
88 Intellectual Property and Copyright Statements . . . . . . . . . . 19
90 1. Introduction
92 1.1. IDNA2008
94 This document is one of a collection that, together, describe the
95 protocol and usage context for a revision of Internationalized Domain
96 Names for Applications (IDNA) that was largely completed in 2008,
97 known within the series and elsewhere as IDNA2008. The series
98 replaces an earlier version of IDNA, described in [RFC3490] and
99 [RFC3491]. It continues to use the Punycode algorithm [RFC3492] and
100 ACE (ASCII-compatible encoding) prefix from that earlier version.
101 The document collection is described in Section 1.3. As indicated
102 there, this document provides definitions and other material that are
103 common to the set.
105 1.1.1. Audiences
107 While many IETF specifications are directed exclusively to protocol
108 implementers, the character of IDNA requires that it be understood
109 and properly used by those whose responsibilities include
111 o Making decisions about what names are permitted in DNS zone files
113 o About policies related to names and naming, and
115 o About the handling of domain name strings in files and systems,
116 even with no immediate intention of looking them up.
118 This document and those concerned with the protocol definition, rules
119 for handling strings that include characters written right-to-left,
120 and the actual list of characters and categories will be of primary
121 interest to protocol implementers. This document and the one
122 containing explanatory material will be of primary interest to
123 others, although they may have to fill in some details by reference
124 to other documents in the set.
126 1.1.2. Normative Language
128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
130 document are to be interpreted as described in RFC 2119 [RFC2119].
132 1.2. Discussion Forum
134 [[ RFC Editor: please remove this section. ]]
136 IDNA2008 is being discussed in the IETF "idnabis" Working Group and
137 on the mailing list idna-update@alvestrand.no
139 1.3. Roadmap of IDNA2008 Documents
141 IDNA2008 consists of the following documents:
143 o This document, containing definitions and other material that are
144 needed for understanding other documents in the set. It is
145 referred to informally in other documents in the set as "Defs" or
146 "Definitions".
148 o A document [IDNA2008-Rationale] that provides an overview of the
149 protocol and associated tables together with explanatory material
150 and some rationale for the decisions that led to IDNA2008. That
151 document also contains advice for registry operations and those
152 who use internationalized domain names. It is referred to
153 informally in other documents in the set as "Rationale". It is
154 not normative.
156 o A document [IDNA2008-Protocol] that describes the core IDNA2008
157 protocol and its operations. In combination with the "Bidi"
158 document described immediately below, it explicitly updates and
159 replaces RFC 3490. It is referred to informally in other
160 documents in the set as "Protocol".
162 o A document [IDNA2008-Bidi] that specifies special rules ("Bidi")
163 for labels that contain characters that are written from right to
164 left.
166 o A specification [IDNA2008-Tables] of the categories and rules that
167 identify the code points allowed in a label written in native
168 character form (defined more specifically as a "U-label" in
169 Section 2.3.1.1 below), based on Unicode 5.1 [Unicode51] code
170 point assignments and additional rules unique to IDNA2008. The
171 Unicode-based rules are expected to be stable across Unicode
172 updates and hence independent of Unicode versions. That
173 specifications obsoletes RFC 3941 and IDN use of the tables to
174 which it refers. It is referred to informally in other documents
175 in the set as "Tables".
177 2. Definitions and Terminology
179 2.1. Characters and Character Sets
181 A code point is an integer value in the codespace of a coded
182 character set. In Unicode, these are integers from 0 to 0x10FFFF.
184 Unicode [Unicode51] is a coded character set with about 100,000
185 characters assigned to code points as of version 5.1. A single
186 Unicode code point is denoted in these documents by "U+" followed by
187 four to six hexadecimal digits, while a range of Unicode code points
188 is denoted by two four to six digit hexadecimal numbers separated by
189 "..", with no prefixes.
191 ASCII means US-ASCII [ASCII], a coded character set containing 128
192 characters associated with code points in the range 0000..007F.
193 Unicode is a superset of ASCII and may be thought of as a
194 generalization of it; it includes all the ASCII characters and
195 associates them with equivalent code points.
197 "Letters" are, informally, generalizations from the ASCII and common-
198 sense understanding of that term, i.e., characters that are used to
199 write text that are not digits, symbols, or punctuation. Formally,
200 they are characters with a Unicode General Category value starting in
201 "L" (see Section 4.5 of [Unicode51]).
203 2.2. DNS-related Terminology
205 When discussing the DNS, this document generally assumes the
206 terminology used in the DNS specifications [RFC1034] [RFC1035]. The
207 term "lookup" is used to describe the combination of operations
208 performed by the IDNA2008 protocol and those actually performed by a
209 DNS resolver. The process of placing an entry into the DNS is
210 referred to as "registration", similar to common contemporary usage
211 in other contexts. Consequently, any DNS zone administration is
212 described as a "registry", regardless of the actual administrative
213 arrangements or level in the DNS tree. More detail about that
214 relationship is included in the "Rationale" document.
216 The term "LDH code point" is defined in this document to refer to the
217 code points associated with ASCII letters (Unicode code points
218 0041..005A and 0061..007A), digits (0030..0039), and the hyphen-minus
219 (U+002D). "LDH" is an abbreviation for "letters, digits, hyphen".
221 The base DNS specifications [RFC1034] [RFC1035] discuss "domain
222 names" and "host names", but many people use the terms
223 interchangeably, as do sections of these specifications. Lack of
224 clarity about that terminology has contributed to confusion about
225 intent in some cases. These documents generally use the term "domain
226 name". When they refer to, e.g., host name syntax restrictions, they
227 explicitly cite the relevant defining documents. The remaining
228 definitions in this subsection are essentially a review: if there is
229 any perceived difference between those definitions and the
230 definitions in the base DNS documents or those cited below, the
231 definitions in the other documents take precedence.
233 A label is an individual component of a domain name. Labels are
234 usually shown separated by dots; for example, the domain name
235 "www.example.com" is composed of three labels: "www", "example", and
236 "com". (The zero-length root label described in RFC 1123 [RFC1123],
237 which can be explicit as in "www.example.com." or implicit as in
238 "www.example.com", is not considered in this specification.) IDNA
239 extends the set of usable characters in labels that are treated as
240 text (as distinct from the binary string labels discussed in RFC 1035
241 and RFC 2181 [RFC2181] and the bitstring ones described in RFC 2673
242 [RFC2673]). For the rest of this document and in the related ones,
243 the term "label" is shorthand for "text label", and "every label"
244 means "every text label".
246 2.3. Terminology Specific to IDNA
248 This section defines some terminology to reduce dependence on terms
249 and definitions that have been problematic in the past.
251 2.3.1. Terms for IDN Label Codings
253 2.3.1.1. IDNA-valid strings, A-label, and U-label
255 To improve clarity, this subsection of the document introduces three
256 new terms. In the next subsection, it defines a historical term to
257 be slightly more precise for IDNA contexts. The relationship among
258 these terms and some others is illustrated in Figure 1.
260 o A string is "IDNA-valid" if it meets all of the requirements of
261 these specifications for an IDNA label. IDNA-valid strings may
262 appear in either of the two forms, defined immediately below, or
263 may, trivially, be ASCII strings that conform to the traditional
264 "hostname" (or "LDH") rule and that do not contain "--" as the
265 third and fourth character. These documents make specific
266 reference to the form appropriate to any context in which the
267 distinction is important.
269 o An "A-label" is the ASCII-Compatible Encoding (ACE, see
270 Section 2.3.1.5) form of an IDNA-valid string. It must be a
271 complete label: IDNA is defined for labels, not for parts of them
272 and not for complete domain names. This means, by definition,
273 that every A-label will begin with the IDNA ACE prefix, "xn--"
274 (see Section 2.3.1.5), followed by a string that is a valid output
275 of the Punycode algorithm and hence a maximum of 59 ASCII
276 characters in length. The prefix and string together must conform
277 to all requirements for a label that can be stored in the DNS
278 including conformance to the rules for the preferred form
279 described in RFC 1034, RFC 1035, and RFC 1123. A string meeting
280 that above requirements is still not an A-label unless it can be
281 decoded into a U-label.
283 o A "U-label" is an IDNA-valid string of Unicode characters, in
284 normalization form NFC and including at least one non-ASCII
285 character, expressed in a standard Unicode Encoding Form -- in an
286 Internet transmission context this will normally be UTF-8 -- and
287 subject to the constraints about permitted characters that are
288 specified in the Protocol and Tables documents as well as the
289 symmetry constraint described. Conversions between U-labels and
290 A-labels are performed according to the "Punycode" specification
291 [RFC3492], adding or removing the ACE prefix as needed.
293 To be valid, U-labels and A-labels must obey an important symmetry
294 constraint. While that constraint may be tested in any of several
295 ways, an A-label must be capable of being produced by conversion from
296 a U-label and a U-label must be capable of being produced by
297 conversion from an A-label. Among other things, this implies that
298 both U-labels and A-labels must be strings in Unicode NFC
299 [Unicode-UAX15] normalized form. These strings MUST contain only
300 characters specified elsewhere in this document series, and only in
301 the contexts indicated as appropriate.
303 Any rules or conventions that apply to DNS labels in general, such as
304 rules about lengths of strings, apply to whichever of the U-label or
305 A-label would be more restrictive. For the U-label, constraints
306 imposed by existing protocols and their presentation forms make the
307 length restriction apply to the length in octets of the UTF-8 form of
308 those labels (which will always be greater than or equal to the
309 length in code points). The exception to this, of course, is that
310 the restriction to ASCII characters does not apply to the U-label.
312 A different way to look at these terms, which may be more clear to
313 some readers, is that U-labels, A-labels, and LDH-labels (see the
314 next subsection) are disjoint categories that, together, make up the
315 forms of legitimate strings for use in domain names that describe
316 hosts. Of the three, only A-labels and LDH-labels can actually
317 appear in DNS zone files or queries; U-labels can appear, along with
318 the other two, in presentation and user interface forms and in
319 selected protocols other than those of the DNS itself. Strings that
320 do not conform to the rules for one of these three categories and, in
321 particular, strings that contain "--" in the third and fourth
322 character position but are:
324 o not A-labels or
326 o cannot be processed as U-labels or A-labels as described in these
327 specifications,
329 are invalid in IDNA-conformant applications as labels in domain names
330 that identify Internet hosts or similar resources.
332 2.3.1.2. LDH-label and Internationalized Label
334 These specifications use the term "LDH-label" strictly to refer to an
335 all-ASCII label that obeys the preferred syntax (often known as
336 "hostname" (from RFC 952 [RFC0952]) or "LDH") conventions and that is
337 not an IDN. It should be stressed that an A-label obeys the
338 "hostname" rules and is sometimes described as "LDH-conformant", or
339 in similar language, but it is not an LDH-label as that term is
340 defined in these specifications.
342 2.3.1.3. Internationalized Domain Name
344 An "internationalized domain name" (IDN) is a domain name that may
345 contain any mixture of LDH-labels, A-labels, or U-labels. This
346 implies that every conventional domain name is an IDN (which implies
347 that it is possible for a domain name to be an IDN without it
348 containing any non-ASCII characters). Just as has been the case with
349 ASCII names, some DNS zone administrators may impose restrictions,
350 beyond those imposed by DNS or IDNA, on the characters or strings
351 that may be registered as labels in their zones. Because of the
352 diversity of characters that can be used in a U-label and the
353 confusion they might cause, such restrictions are mandatory for IDN
354 registries and zones even though the particular restrictions are not
355 part of these specifications. Because these restrictions, commonly
356 known as "registry restrictions", only affect what can be registered
357 and not lookup processing, they have no effect on the syntax or
358 semantics of DNS protocol messages; a query for a name that matches
359 no records will yield the same response regardless of the reason why
360 it is not in the zone. Clients issuing queries or interpreting
361 responses cannot be assumed to have any knowledge of zone-specific
362 restrictions or conventions. See the section on registration policy
363 in [IDNA2008-Rationale] for additional discussion.
365 "Internationalized label" is used when a term is needed to refer to a
366 single label of an IDN, i.e., one that might be any of an LDH-label,
367 A-label, or U-label. There are some standardized DNS label formats,
368 such as those for service location (SRV) records [RFC2782], that do
369 not fall into any of the three categories and hence are not
370 internationalized labels.
372 2.3.1.4. Label Equivalence
374 In IDNA, equivalence of labels is defined in terms of the A-labels.
375 If the A-labels are equal in a case-independent comparison, then the
376 labels are considered equivalent, no matter how they are represented.
377 Because of the isomorphism of A-labels and U-labels in IDNA2008, it
378 is possible to compare U-labels directly; see [IDNA2008-Protocol] for
379 details. Traditional LDH labels already have a notion of
380 equivalence: within that list of characters, upper case and lower
381 case are considered equivalent. The IDNA notion of equivalence is an
382 extension of that older notion. Equivalent labels in IDNA are
383 treated as alternate forms of the same label, just as "foo" and "Foo"
384 are treated as alternate forms of the same label.
386 2.3.1.5. ACE Prefix
388 The "ACE prefix" is defined in this document to be a string of ASCII
389 characters "xn--" that appears at the beginning of every A-label.
390 "ACE" stands for "ASCII-Compatible Encoding".
392 2.3.1.6. Domain Name Slot
394 A "domain name slot" is defined in this document to be a protocol
395 element or a function argument or a return value (and so on)
396 explicitly designated for carrying a domain name. Examples of domain
397 name slots include: the QNAME field of a DNS query; the name argument
398 of the gethostbyname() or getaddrinfo() standard C library functions;
399 the part of an email address following the at-sign (@) in the
400 parameter to the SMTP MAIL or RCPT commands or the "From:" field of
401 an email message header; and the host portion of the URI in the src
402 attribute of an HTML tag. A string that has the syntax of a
403 domain name but that appears in general text is not in a domain name
404 slot. For example, a domain name appearing in the plain text body of
405 an email message is not occupying a domain name slot.
407 An "IDN-aware domain name slot" is defined for this set of documents
408 to be a domain name slot explicitly designated for carrying an
409 internationalized domain name as defined in this document. The
410 designation may be static (for example, in the specification of the
411 protocol or interface) or dynamic (for example, as a result of
412 negotiation in an interactive session).
414 An "IDN-unaware domain name slot" is defined for this set of
415 documents to be any domain name slot that is not an IDN-aware domain
416 name slot. Obviously, this includes any domain name slot whose
417 specification predates IDNA.
419 The figure on this page illustrates the relationships among some of
420 the terms defined above. The parenthesized numbers refer to the
421 notes below the figure.
423 _______________________ _______________________
424 | ASCII Labels | | Non-ASCII |
425 | | | |
426 | ___________________| | __________________|
427 | |LDH-conforming (1)| | | U-label (2) |
428 | | | | |_________________|
429 | | ________________| | | |
430 | | | LDH-label | | | Binary Label |
431 | | |_______________| | | (including |
432 | | | A-label | | | high bit on) |
433 | | |_______________| | |_________________|
434 | | | | | | |
435 | | | Broken IDN | | | Bit String |
436 | | | e.g., xn--?,| | | Label |
437 | | | abc--def | | |_________________|
438 | | |_______________| |______________________|
439 | |__________________|
440 | ___________________|
441 | |Not-LDH-Conforming|
442 | | |
443 | | ________________|
444 | | |SRV & SRV-like |
445 | | | e.g., _tcp |
446 | | |_______________|
447 | | | Leading or |
448 | | | trailing |
449 | | | hyphens |
450 | | |_______________|
451 | | | Other non-LDH |
452 | | | ASCII chars |
453 | | | e.g., #$%&_ |
454 | | |_______________|
455 | |__________________|
456 |_____________________|
458 (1) These subtypes are indistinguishable to IDNA-unaware
459 applications.
460 (2) To IDNA-unaware applications, U-labels are
461 indistinguishable from Binary ones.
463 Figure 1: IDNA and Related DNS Terminology Space
465 2.3.2. Strings Proposed to be Used or Looked Up as Labels
467 Strings are encountered at many places in these specifications that
468 are expected to be processed as labels of particular types but that
469 are not yet fully validated to conform to the requirements for the
470 particular type of label in question. If XYZ is a type of label
471 (e.g., "A" for A-label or "U" for a U-label), then the term "putative
472 XYZ-label" is used to refer to such a string before it is fully
473 validated or tested.
475 Similarly, terms similar to "a string in the form of an XYZ-label"
476 are used to refer to a string that appears to obey the syntax for an
477 XYZ-label on superficial examination. Specifically, a string that
478 would comply with the LDH syntax except that some characters are non-
479 ASCII is considered to be in the form of a U-label and one that
480 starts in "xn--" and is otherwise all-ASCII is considered to be in
481 the form of an A-label.
483 2.3.3. Order of Characters in Labels
485 Because IDN labels may contain characters that are read, and
486 preferentially displayed, from right to left, there is a potential
487 ambiguity about which character in a label is "first". For the
488 purposes of these specifications, labels are considered, and
489 characters numbered, strictly in the order in which they appear "on
490 the wire". That order is equivalent to the leftmost character being
491 treated as first in a label that is read left-to-right and to the
492 righmost character being first in a label that is read right-to-left.
493 The "Bidi" specification contains additional discussion of the
494 conditions that influence reading order.
496 2.3.4. Punycode is an Algorithm, not a Name or Adjective
498 There has been some confusion about whether a "Punycode string" does
499 or does not include the ACE prefix and about whether it is required
500 that such strings could have been the output of the ToASCII operation
501 (see RFC 3490, Section 4 [RFC3490]). This specification discourages
502 the use of the term "Punycode" to describe anything but the encoding
503 method and algorithm of [RFC3492]. The terms defined above are
504 preferred as much more clear than the term "Punycode string".
506 3. IANA Considerations
508 Actions for IANA are specified in other documents in this series
509 [IDNA2008-Protocol] [IDNA2008-Tables]. An overview of the
510 relationships among the various IANA registries appears in
511 [IDNA2008-Rationale]. This document does not specify any actions for
512 IANA.
514 4. Security Considerations
516 4.1. General Issues
518 Security on the Internet partly relies on the DNS. Thus, any change
519 to the characteristics of the DNS can change the security of much of
520 the Internet.
522 Domain names are used by users to identify and connect to Internet
523 servers. The security of the Internet is compromised if a user
524 entering a single internationalized name is connected to different
525 servers based on different interpretations of the internationalized
526 domain name. In addition to characters that are permitted by
527 IDNA2003 and its mapping conventions, the current specification
528 changes the interpretation of a few characters that were mapped to
529 others in the earlier version; zone administrators should be aware of
530 the problems that might raise and take appropriate measures. The
531 context for this issue is discussed in more detail in
532 [IDNA2008-Rationale]).
534 In addition to the Security Considerations material that appears in
535 this document, [IDNA2008-Bidi] contains a discussion of security
536 issues specific to labels containing characters from scripts that are
537 normally written right to left.
539 4.2. Local Character Set Issues
541 When systems use local character sets other than ASCII and Unicode,
542 these specifications leave the problem of converting between the
543 local character set and Unicode up to the application or local
544 system. If different applications (or different versions of one
545 application) implement different rules for conversions among coded
546 character sets, they could interpret the same name differently and
547 contact different servers. This problem is not solved by security
548 protocols, such as Transport Layer Security (TLS) [RFC5246], that do
549 not take local character sets into account.
551 4.3. Visually Similar Characters
553 To help prevent confusion between characters that are visually
554 similar, it is suggested that implementations provide visual
555 indications where a domain name contains multiple scripts (or what
556 are considered multiple scripts in a local environment in which some
557 mixed-script use is normal). Such mechanisms can also be used to
558 show when a name contains a mixture of simplified and traditional
559 Chinese characters, or to distinguish zero and one from upper-case
560 "O" and lower-case "L". DNS zone administrators may impose
561 restrictions (subject to the limitations identified elsewhere in
562 these documents) that try to minimize characters that have similar
563 appearance or similar interpretations. It is worth noting that there
564 are no comprehensive technical solutions to the problems of
565 confusable characters. One can reduce the extent of the problems in
566 various ways, but probably never eliminate it. Some specific
567 suggestions about identification and handling of confusable
568 characters appear in a Unicode Consortium publication
569 [Unicode-UTR36].
571 4.4. IDNA Lookup, Registration, and the Base DNS Specifications
573 The Protocol specification [IDNA2008-Protocol] describes procedures
574 for registering and looking up labels that are not compatible with
575 the preferred syntax described in the base DNS specifications (STD13
576 [RFC1034] [RFC1035] and Host Requirements [RFC1123]) because they
577 contain non-ASCII characters. These procedures depend on the use of
578 a special ASCII-compatible encoding form that contains only
579 characters permitted in host names by those earlier specifications.
580 The encoding used is Punycode [RFC3492]. No security issues such as
581 string length increases or new allowed values are introduced by the
582 encoding process or the use of these encoded values, apart from those
583 introduced by the ACE encoding itself.
585 Domain names (or portions of them) are sometimes compared against a
586 set of domains to be given special treatment if a match occurs, e.g.,
587 treated as more privileged than others or blocked in some way. In
588 such situations, it is especially important that the comparisons be
589 done properly, as specified in the Requirements section of
590 [IDNA2008-Protocol]. For labels already in ASCII form (i.e., are
591 LDH-labels or A-labels), the proper comparison reduces to the same
592 case-insensitive ASCII comparison that has always been used for ASCII
593 labels.
595 The introduction of IDNA means that any existing labels that start
596 with the ACE prefix would be construed as A-labels, at least until
597 they failed one of the relevant tests, whether or not that was the
598 intent of the zone administrator or registrant. There is no evidence
599 that this has caused any practical problems since RFC 3490 was
600 adopted, but the risk still exists in principle.
602 4.5. Security Differences from IDNA2003
604 The registration and lookup models described in this set of documents
605 change the mechanisms available for lookup applications to determine
606 the validity of labels they encounter. In some respects, the ability
607 to test is strengthened. For example, putative labels that contain
608 unassigned code points will now be rejected, while IDNA2003 permitted
609 them (something that is now recognized as a considerable source of
610 risk). On the other hand, the protocol specification no longer
611 assumes that the application that looks up a name will be able to
612 determine, and apply, information about the protocol version used in
613 registration. In theory, that may increase risk since the
614 application will be able to do less pre-lookup validation. In
615 practice, the protection afforded by that test has been largely
616 illusory for reasons explained in RFC 4690 [RFC4690] and elsewhere in
617 these documents.
619 Any change to the Stringprep [RFC3454] procedure that is profiled and
620 used in IDNA2003, or, more broadly, the IETF's model of the use of
621 internationalized character strings in different protocols, creates
622 some risk of inadvertent changes to those protocols, invalidating
623 deployed applications or databases, and so on. But these
624 specifications do not change Stringprep at all; they merely bypass
625 it. Because these documents do not depend on Stringprep, the
626 question of upgrading other protocols that do have that dependency
627 can be left to experts on those protocols: the IDNA changes and
628 possible upgrades to security protocols or conventions are
629 independent issues.
631 4.6. Summary
633 No mechanism involving names or identifiers alone can protect against
634 a wide variety of security threats and attacks that are largely
635 independent of the naming or identification system. These attacks
636 include spoofed pages, DNS query trapping and diversion, and so on.
638 5. Acknowledgments
640 The initial version of this document was created largely by
641 extracting text from the "rationale" document [IDNA2008-Rationale].
642 See the section of this name, and the one entitled "Contributors", in
643 it.
645 Specific textual suggestions after the extraction process came from
646 Vint Cerf and Bill McQuillan.
648 6. References
649 6.1. Normative References
651 [ASCII] American National Standards Institute (formerly United
652 States of America Standards Institute), "USA Code for
653 Information Interchange", ANSI X3.4-1968, 1968.
655 ANSI X3.4-1968 has been replaced by newer versions with
656 slight modifications, but the 1968 version remains
657 definitive for the Internet.
659 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
660 STD 13, RFC 1034, November 1987.
662 [RFC1035] Mockapetris, P., "Domain names - implementation and
663 specification", STD 13, RFC 1035, November 1987.
665 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
666 and Support", STD 3, RFC 1123, October 1989.
668 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
669 Requirement Levels", BCP 14, RFC 2119, March 1997.
671 [Unicode-UAX15]
672 The Unicode Consortium, "Unicode Standard Annex #15:
673 Unicode Normalization Forms", March 2008,
674 .
676 [Unicode51]
677 The Unicode Consortium, "The Unicode Standard, Version
678 5.1.0", 2008.
680 defined by: The Unicode Standard, Version 5.0, Boston, MA,
681 Addison-Wesley, 2007, ISBN 0-321-48091-0, as amended by
682 Unicode 5.1.0
683 (http://www.unicode.org/versions/Unicode5.1.0/).
685 6.2. Informative References
687 [IDNA2008-Bidi]
688 Alvestrand, H. and C. Karp, "An updated IDNA criterion for
689 right to left scripts", July 2008, .
692 [IDNA2008-Protocol]
693 Klensin, J., "Internationalized Domain Names in
694 Applications (IDNA): Protocol", November 2008, .
697 [IDNA2008-Rationale]
698 Klensin, J., "Internationalized Domain Names for
699 Applications (IDNA): Background, Explanation, and
700 Rationale", November 2008, .
703 [IDNA2008-Tables]
704 Faltstrom, P., "The Unicode Code Points and IDNA",
705 July 2008, .
708 A version of this document is available in HTML format at
709 http://stupid.domain.name/idnabis/
710 draft-ietf-idnabis-tables-02.html
712 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
713 host table specification", RFC 952, October 1985.
715 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
716 Specification", RFC 2181, July 1997.
718 [RFC2673] Crawford, M., "Binary Labels in the Domain Name System",
719 RFC 2673, August 1999.
721 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
722 specifying the location of services (DNS SRV)", RFC 2782,
723 February 2000.
725 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
726 Internationalized Strings ("stringprep")", RFC 3454,
727 December 2002.
729 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
730 "Internationalizing Domain Names in Applications (IDNA)",
731 RFC 3490, March 2003.
733 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
734 Profile for Internationalized Domain Names (IDN)",
735 RFC 3491, March 2003.
737 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
738 for Internationalized Domain Names in Applications
739 (IDNA)", RFC 3492, March 2003.
741 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and
742 Recommendations for Internationalized Domain Names
743 (IDNs)", RFC 4690, September 2006.
745 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
746 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
748 [Unicode-UTR36]
749 The Unicode Consortium, "Unicode Technical Report #36:
750 Unicode Security Considerations", July 2008,
751 .
753 Appendix A. Change Log
755 [[RFC Editor: Please remove this appendix]]
757 A.1. Version -00
759 This document was created by pulling selected material out of
760 draft-ietf-idnabis-rationale-03 ("Rationale") after a WG consensus
761 call indicated that the rearrangement was appropriate. Mark Davis
762 made the major contribution of getting the process started by
763 identifying particular sections to be moved, even though this draft
764 does not completely reflect his list.
766 For Version -00 only, each section is identified with the associated
767 former section of Rationale-03. Those sections were edited after
768 incorporation into this document, so "Formerly" should be interpreted
769 very loosely.
771 A.2. Version -01
773 o Typographical errors corrected and some sections slightly renamed
774 for clarity.
776 o Other adjustments made to synchronize with current versions of
777 "Rationale" and "Protocol".
779 A.3. Version -02
781 o All back pointers to section numbers in Rationale have been
782 removed.
784 o Some definitions clarified. Added one about string order.
786 o Usual small editorial tuning.
788 A.4. Version -03
790 o Additional fine tuning based on discussions during and immediately
791 before IETF 72.
793 A.5. Version -04
795 o Corrections of text and improvement of definitions based on
796 discussions after -03 was released.
798 o Discussion of label comparisons tightened and made more consistent
799 with Protocol.
801 o Definitions of categories of labels supplemented with a picture.
803 o Explicit text added (Section 2.3.2) to define strings that look
804 like A-labels or U-labels but are not.
806 A.6. Version -05
808 o Consolidated Security Considerations sections, moving material
809 from Protocol and Rationale here.
811 Author's Address
813 John C Klensin
814 1770 Massachusetts Ave, Ste 322
815 Cambridge, MA 02140
816 USA
818 Phone: +1 617 245 1457
819 Email: john+ietf@jck.com
821 Full Copyright Statement
823 Copyright (C) The IETF Trust (2008).
825 This document is subject to the rights, licenses and restrictions
826 contained in BCP 78, and except as set forth therein, the authors
827 retain all their rights.
829 This document and the information contained herein are provided on an
830 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
831 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
832 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
833 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
834 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
835 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
837 Intellectual Property
839 The IETF takes no position regarding the validity or scope of any
840 Intellectual Property Rights or other rights that might be claimed to
841 pertain to the implementation or use of the technology described in
842 this document or the extent to which any license under such rights
843 might or might not be available; nor does it represent that it has
844 made any independent effort to identify any such rights. Information
845 on the procedures with respect to rights in RFC documents can be
846 found in BCP 78 and BCP 79.
848 Copies of IPR disclosures made to the IETF Secretariat and any
849 assurances of licenses to be made available, or the result of an
850 attempt made to obtain a general license or permission for the use of
851 such proprietary rights by implementers or users of this
852 specification can be obtained from the IETF on-line IPR repository at
853 http://www.ietf.org/ipr.
855 The IETF invites any interested party to bring to its attention any
856 copyrights, patents or patent applications, or other proprietary
857 rights that may cover technology that may be required to implement
858 this standard. Please address the information to the IETF at
859 ietf-ipr@ietf.org.