idnits 2.17.1
draft-ietf-idn-idna-11.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** Missing expiration date. The document expiration date should appear on
the first and last page.
** The document is more than 15 pages and seems to lack a Table of Contents.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== The page length should not exceed 58 lines per page, but there was 1
longer page, the longest (page 1) being 854 lines
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** There are 2 instances of too long lines in the document, the longest one
being 2 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- 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.)
-- Couldn't find a document date in the document -- date freshness check
skipped.
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'RFC2136' is mentioned on line 836, but not defined
== Unused Reference: 'UAX9' is defined on line 701, but no explicit
reference was found in the text
-- Obsolete informational reference (is this intentional?): RFC 2535 (ref.
'DNSSEC') (Obsoleted by RFC 4033, RFC 4034, RFC 4035)
Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 Internet Draft Patrik Faltstrom
2 draft-ietf-idn-idna-11.txt Cisco
3 Auguest 29, 2002 Paul Hoffman
4 Expires in six months IMC & VPNC
5 Adam M. Costello
6 UC Berkeley
8 Internationalizing Domain Names in Applications (IDNA)
10 Status of this Memo
12 This document is an Internet-Draft and is in full conformance with all
13 provisions of Section 10 of RFC2026.
15 Internet-Drafts are working documents of the Internet Engineering Task
16 Force (IETF), its areas, and its working groups. Note that other groups
17 may also distribute working documents as Internet-Drafts.
19 Internet-Drafts are draft documents valid for a maximum of six months
20 and may be updated, replaced, or obsoleted by other documents at any
21 time. It is inappropriate to use Internet-Drafts as reference material
22 or to cite them other than as "work in progress."
24 The list of current Internet-Drafts can be accessed at
25 http://www.ietf.org/ietf/1id-abstracts.txt
27 The list of Internet-Draft Shadow Directories can be accessed at
28 http://www.ietf.org/shadow.html.
30 Abstract
32 Until now, there has been no standard method for domain names to use
33 characters outside the ASCII repertoire. This document defines
34 internationalized domain names (IDNs) and a mechanism called IDNA for
35 handling them in a standard fashion. IDNs use characters drawn from a
36 large repertoire (Unicode), but IDNA allows the non-ASCII characters to
37 be represented using only the ASCII characters already allowed in
38 so-called host names today. This backward-compatible representation is
39 required in existing protocols like DNS, so that IDNs can be introduced
40 with no changes to the existing infrastructure. IDNA is only meant for
41 processing domain names, not free text.
43 1. Introduction
45 IDNA works by allowing applications to use certain ASCII name labels
46 (beginning with a special prefix) to represent non-ASCII name labels.
47 Lower-layer protocols need not be aware of this; therefore IDNA does not
48 depend on changes to any infrastructure. In particular, IDNA does not
49 depend on any changes to DNS servers, resolvers, or protocol elements,
50 because the ASCII name service provided by the existing DNS is entirely
51 sufficient for IDNA.
53 This document does not require any applications to conform to IDNA, but
54 applications can elect to use IDNA in order to support IDN while
55 maintaining interoperability with existing infrastructure. If an
56 application wants to use non-ASCII characters in domain names, IDNA is
57 the only currently-defined option. Adding IDNA support to an existing
58 application entails changes to the application only, and leaves room for
59 flexibility in the user interface.
61 A great deal of the discussion of IDN solutions has focused on
62 transition issues and how IDN will work in a world where not all of the
63 components have been updated. Proposals that were not chosen by the IDN
64 Working Group would depend on user applications, resolvers, and DNS
65 servers being updated in order for a user to use an internationalized
66 domain name. Rather than rely on widespread updating of all components,
67 IDNA depends on updates to user applications only; no changes are needed
68 to the DNS protocol or any DNS servers or the resolvers on user's
69 computers.
71 1.1 Brief overview for application developers
73 Applications can use IDNA to support internationalized domain names
74 anywhere that ASCII domain names are already supported, including DNS
75 master files and resolver interfaces. (Applications can also define
76 protocols and interfaces that support IDNs directly using non-ASCII
77 representations. IDNA does not prescribe any particular representation
78 for new protocols, but it still defines which names are valid and how
79 they are compared.)
81 The IDNA protocol is contained completely within applications. It is not
82 a client-server or peer-to-peer protocol: everything is done inside the
83 application itself. When used with a DNS resolver library, IDNA is
84 inserted as a "shim" between the application and the resolver library.
85 When used for writing names into a DNS zone, IDNA is used just before
86 the name is committed to the zone.
88 There are two operations described in section 4 of this document:
90 - The ToASCII operation is used before sending an IDN to something that
91 expects ASCII names (such as a resolver) or writing an IDN into a place
92 that expects ASCII names (such as a DNS master file).
94 - The ToUnicode operation is used when displaying names to users, for
95 example names obtained from a DNS zone.
97 It is important to note that the ToASCII operation can fail. If it fails
98 when processing a domain name, that domain name cannot be used as an
99 internationalized domain name and the application has to have some
100 method of dealing with this failure.
102 IDNA requires that implementations process input strings with Nameprep
103 [NAMEPREP], which is a profile of Stringprep [STRINGPREP], and then with
104 Punycode [PUNYCODE]. Implementations of IDNA MUST fully implement
105 Nameprep and Punycode; neither Nameprep nor Punycode are optional.
107 2 Terminology
109 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
110 "MAY" in this document are to be interpreted as described in RFC 2119
111 [RFC2119].
113 A code point is an integral value associated with a character in a coded
114 character set.
116 Unicode [UNICODE] is a coded character set containing tens of thousands
117 of characters. A single Unicode code point is denoted by "U+" followed
118 by four to six hexadecimal digits, while a range of Unicode code points
119 is denoted by two hexadecimal numbers separated by "..", with no
120 prefixes.
122 ASCII means US-ASCII [USASCII], a coded character set containing 128
123 characters associated with code points in the range 0..7F. Unicode is an
124 extension of ASCII: it includes all the ASCII characters and associates
125 them with the same code points.
127 The term "LDH code points" is defined in this document to mean the code
128 points associated with ASCII letters, digits, and the hyphen-minus; that
129 is, U+002D, 30..39, 41..5A, and 61..7A. "LDH" is an abbreviation for
130 "letters, digits, hyphen".
132 [STD13] talks about "domain names" and "host names", but many people use
133 the terms interchangeably. Further, because [STD13] was not terribly
134 clear, many people who are sure they know the exact definitions of each
135 of these terms disagree on the definitions. In this document the term
136 "domain name" is used in general. This document explicitly cites [STD3]
137 whenever referring to the host name syntax restrictions defined therein.
139 A label is an individual part of a domain name. Labels are usually shown
140 separated by dots; for example, the domain name "www.example.com" is
141 composed of three labels: "www", "example", and "com". (The zero-length
142 root label described in [STD13], which can be explicit as in
143 "www.example.com." or implicit as in "www.example.com", is not
144 considered a label in this specification.) IDNA extends the set of
145 usable characters in labels that are text. For the rest of this
146 document, the term "label" is shorthand for "text label", and "every
147 label" means "every text label".
149 An "internationalized domain name" (IDN) is a domain name for which the
150 ToASCII operation (see section 4) can be applied to each label without
151 failing. This document does not attempt to define an "internationalized
152 host name". It is expected that some name-handling bodies, such as large
153 zone administrators and groups of affiliated zone administrators, will
154 want to limit the characters allowed in IDNs further than what is
155 specified in this document, such as to prohibit additional characters
156 that they feel are unneeded or harmful in registered domain names.
158 In IDNA, equivalence of labels is defined in terms of the ToASCII
159 operation, which constructs an ASCII form for a given label. Labels are
160 defined to be equivalent if and only if their ASCII forms produced by
161 ToASCII match using a case-insensitive ASCII comparison. Traditional
162 ASCII labels already have a notion of equivalence: upper case and lower
163 case are considered equivalent. The IDNA notion of equivalence is an
164 extension of the old notion. Equivalent labels in IDNA are treated as
165 alternate forms of the same label, just as "foo" and "Foo" are treated
166 as alternate forms of the same label.
168 An "internationalized label" is a label composed of characters from the
169 Unicode character set; note, however, that not every string of Unicode
170 characters can be an internationalized label.
172 To allow internationalized labels to be handled by existing
173 applications, IDNA uses an "ACE label" (ACE stands for ASCII Compatible
174 Encoding), which can be represented using only ASCII characters but is
175 equivalent to a label containing non-ASCII characters. More rigorously,
176 an ACE label is defined to be any label that the ToUnicode operation
177 would alter. For every internationalized label that cannot be directly
178 represented in ASCII, there is an equivalent ACE label. An ACE label
179 always begins with the ACE prefix defined in section 5. The conversion
180 of labels to and from the ACE form is specified in section 4.
182 The "ACE prefix" is defined in this document to be a string of ASCII
183 characters that appears at the beginning of every ACE label. It is
184 specified in section 5.
186 A "domain name slot" is defined in this document to be a protocol
187 element or a function argument or a return value (and so on) explicitly
188 designated for carrying a domain name. Examples of domain name slots
189 include: the QNAME field of a DNS query; the name argument of the
190 gethostbyname() library function; the part of an email address following
191 the at-sign (@) in the From: field of an email message header; and the
192 host portion of the URI in the src attribute of an HTML ![]()
tag.
193 General text that just happens to contain a domain name is not a domain
194 name slot; for example, a domain name appearing in the plain text body
195 of an email message is not occupying a domain name slot.
197 An "IDN-aware domain name slot" is defined in this document to be a
198 domain name slot explicitly designated for carrying an internationalized
199 domain name as defined in this document. The designation may be static
200 (for example, in the specification of the protocol or interface) or
201 dynamic (for example, as a result of negotiation in an interactive
202 session).
204 An "IDN-unaware domain name slot" is defined in this document to be any
205 domain name slot that is not an IDN-aware domain name slot. Obviously,
206 this includes any domain name slot whose specification predates IDNA.
208 3. Requirements and applicability
210 3.1 Requirements
212 IDNA conformance means adherence to the following four requirements:
214 1) Whenever dots are used as label separators, the following characters
215 MUST be recognized as dots: U+002E (full stop), U+3002 (ideographic full
216 stop), U+FF0E (fullwidth full stop), U+FF61 (halfwidth ideographic full
217 stop).
219 2) Whenever a domain name is put into an IDN-unaware domain name slot
220 (see section 2), it MUST contain only ASCII characters.
221 Given an internationalized domain name (IDN), an equivalent domain name
222 satisfying this requirement can be obtained by applying the ToASCII
223 operation (see section 4) to each label and, if dots are
224 used as label separators, changing all the label separators to U+002E.
226 3) ACE labels obtained from domain name slots SHOULD be hidden from
227 users except when the use of the non-ASCII form would cause problems or
228 when the ACE form is explicitly requested. Given an internationalized
229 domain name, an equivalent domain name containing no ACE labels can be
230 obtained by applying the ToUnicode operation (see section 4) to each
231 label. When requirements 2 and 3 both apply, requirement 2 takes
232 precedence.
234 4) Whenever two labels are compared, they MUST be considered to match if
235 and only if they are equivalent, that is, their ASCII forms (obtained by
236 applying ToASCII) match using a case-insensitive ASCII comparison.
237 Whenever two names are compared, they MUST be considered to match if and
238 only if their corresponding labels match, regardless of whether the
239 names use the same forms of label separators.
241 3.2 Applicability
243 IDNA is applicable to all domain names in all domain name slots except
244 where it is explicitly excluded.
246 This implies that IDNA is applicable to many protocols that predate
247 IDNA. Note that IDNs occupying domain name slots in those protocols
248 MUST be in ASCII form (see section 3.1, requirement 2).
250 3.2.1. DNS resource records
252 IDNA does not apply to domain names in the NAME and RDATA fields of DNS
253 resource records whose CLASS is not IN. This exclusion applies to every
254 non-IN class, present and future, except where future standards override
255 this exclusion by explicitly inviting the use of IDNA.
257 There are currently no other exclusions on the applicability of IDNA to
258 DNS resource records; it depends entirely on the CLASS, and not on the
259 TYPE. This will remain true, even as new types are defined, unless
260 there is a compelling reason for a new type to complicate matters by
261 imposing type-specific rules.
263 3.2.2. Non-domain-name data types stored in domain names
265 Although IDNA enables the representation of non-ASCII characters in
266 domain names, that does not imply that IDNA enables the representation
267 of non-ASCII characters in other data types that are stored in domain
268 names. For example, an email address local part is sometimes stored in
269 a domain label (hostmaster@example.com would be represented as
270 hostmaster.example.com in the RDATA field of an SOA record). IDNA does
271 not update the existing email standards, which allow only ASCII
272 characters in local parts. Therefore, unless the email standards are
273 revised to invite the use of IDNA for local parts, a domain label that
274 holds the local part of an email address SHOULD NOT begin with the ACE
275 prefix, and even if it does, it is to be interpreted literally as a
276 local part that happens to begin with the ACE prefix.
278 4. Conversion operations
280 An application converts a domain name put into an IDN-unaware slot or
281 displayed to a user. This section specifies the steps to perform in the
282 conversion, and the ToASCII and ToUnicode operations.
284 The input to ToASCII or ToUnicode is a single label that is a sequence
285 of Unicode code points (remember that all ASCII code points are also
286 Unicode code points). If a domain name is represented using a character
287 set other than Unicode or US-ASCII, it will first need to be transcoded
288 to Unicode.
290 Starting from a whole domain name, the steps that an application takes
291 to do the conversions are:
293 1) Decide whether the domain name is a "stored string" or a "query
294 string" as described in [STRINGPREP]. If this conversion follows the
295 "queries" rule from [STRINGPREP], set the flag called "AllowUnassigned".
297 2) Split the domain name into individual labels as described in section
298 3.1. The labels do not include the separator.
300 3) For each label, decide whether or not to enforce the restrictions on
301 ASCII characters in host names [STD3]. If the restrictions are to be
302 enforced, set the flag called "UseSTD3ASCIIRules" for that label.
304 4) Process each label with either the ToASCII or the ToUnicode
305 operation. Use the ToASCII operation if you are about to put
306 the name into an IDN-unaware slot. Use the ToUnicode operation if you
307 are displaying the name to a user.
309 5) If ToASCII was applied in step 4 and dots are used as label
310 separators, change all the label separators to U+002E (full stop).
312 The following two subsections define the ToASCII and ToUnicode
313 operations that are used in step 4.
315 4.1 ToASCII
317 The ToASCII operation takes a sequence of Unicode code points that make
318 up one label and transforms it into a sequence of code points in the
319 ASCII range (0..7F). If ToASCII succeeds, the original sequence and the
320 resulting sequence are equivalent labels.
322 It is important to note that the ToASCII operation can fail. ToASCII
323 fails if any step of it fails. If any step of the ToASCII operation
324 fails on any label in a domain name, that domain name MUST NOT be used
325 as an internationalized domain name. The application needs to have some
326 method of dealing with this failure.
328 The inputs to ToASCII are a sequence of code points, the AllowUnassigned
329 flag, and the UseSTD3ASCIIRules flag. The output of ToASCII is either a
330 sequence of ASCII code points or a failure condition.
332 ToASCII never alters a sequence of code points that are all in the ASCII
333 range to begin with (although it could fail). Applying the ToASCII
334 operation multiple times has exactly the same effect as applying it just
335 once.
337 ToASCII consists of the following steps:
339 1. If all code points in the sequence are in the ASCII range (0..7F)
340 then skip to step 3.
342 2. Perform the steps specified in [NAMEPREP] and fail if there is
343 an error. The AllowUnassigned flag is used in [NAMEPREP].
345 3. If the UseSTD3ASCIIRules flag is set, then perform these checks:
347 (a) Verify the absence of non-LDH ASCII code points; that is,
348 the absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.
350 (b) Verify the absence of leading and trailing hyphen-minus;
351 that is, the absence of U+002D at the beginning and end of
352 the sequence.
354 4. If all code points in the sequence are in the ASCII range
355 (0..7F), then skip to step 8.
357 5. Verify that the sequence does NOT begin with the ACE prefix.
359 6. Encode the sequence using the encoding algorithm in [PUNYCODE]
360 and fail if there is an error.
362 7. Prepend the ACE prefix.
364 8. Verify that the number of code points is in the range 1 to 63
365 inclusive.
367 4.2 ToUnicode
369 The ToUnicode operation takes a sequence of Unicode code points that
370 make up one label and returns a sequence of Unicode code points. If the
371 input sequence is a label in ACE form, then the result is an equivalent
372 internationalized label that is not in ACE form, otherwise the original
373 sequence is returned unaltered.
375 ToUnicode never fails. If any step fails, then the original input
376 sequence is returned immediately in that step.
378 The inputs to ToUnicode are a sequence of code points, the
379 AllowUnassigned flag, and the UseSTD3ASCIIRules flag. The output of
380 ToUnicode is always a sequence of Unicode code points.
382 1. If all code points in the sequence are in the ASCII range (0..7F)
383 then skip to step 3.
385 2. Perform the steps specified in [NAMEPREP] and fail if there is an
386 error. (If step 3 of ToASCII is also performed here, it will not
387 affect the overall behavior of ToUnicode, but it is not
388 necessary.) The AllowUnassigned flag is used in [NAMEPREP].
390 3. Verify that the sequence begins with the ACE prefix, and save a
391 copy of the sequence.
393 4. Remove the ACE prefix.
395 5. Decode the sequence using the decoding algorithm in [PUNYCODE]
396 and fail if there is an error. Save a copy of the result of
397 this step.
399 6. Apply ToASCII.
401 7. Verify that the result of step 6 matches the saved copy from
402 step 3, using a case-insensitive ASCII comparison.
404 8. Return the saved copy from step 5.
406 5. ACE prefix
408 [[ Note to the IESG and Internet Draft readers: The two uses of the
409 string "IESG--" below are to be changed at time of publication to a
410 prefix which fulfills the requirements in the first paragraph. IANA will
411 assign this value. ]]
413 The ACE prefix, used in the conversion operations (section 4), is two
414 alphanumeric ASCII characters followed by two hyphen-minuses. It cannot
415 be any of the prefixes already used in earlier documents, which includes
416 the following: "bl--", "bq--", "dq--", "lq--", "mq--", "ra--", "wq--"
417 and "zq--". The ToASCII and ToUnicode operations MUST recognize the ACE
418 prefix in a case-insensitive manner.
420 The ACE prefix for IDNA is "IESG--".
422 This means that an ACE label might be "IESG--de-jg4avhby1noc0d", where
423 "de-jg4avhby1noc0d" is the part of the ACE label that is generated by
424 the encoding steps in [PUNYCODE].
426 While all ACE labels begin with the ACE prefix, not all labels beginning
427 with the ACE prefix are necessarily ACE labels. Non-ACE labels that
428 begin with the ACE prefix will confuse users and SHOULD NOT be allowed
429 in DNS zones.
431 6. Implications for typical applications using DNS
433 In IDNA, applications perform the processing needed to input
434 internationalized domain names from users, display internationalized
435 domain names to users, and process the inputs and outputs from DNS and
436 other protocols that carry domain names.
438 The components and interfaces between them can be represented
439 pictorially as:
441 +------+
442 | User |
443 +------+
444 ^
445 | Input and display: local interface methods
446 | (pen, keyboard, glowing phosphorus, ...)
447 +-------------------|-------------------------------+
448 | v |
449 | +-----------------------------+ |
450 | | Application | |
451 | | (ToASCII and ToUnicode | |
452 | | operations may be | |
453 | | called here) | |
454 | +-----------------------------+ |
455 | ^ ^ | End system
456 | | | |
457 | Call to resolver: | | Application-specific |
458 | ACE | | protocol: |
459 | v | ACE unless the |
460 | +----------+ | protocol is updated |
461 | | Resolver | | to handle other |
462 | +----------+ | encodings |
463 | ^ | |
464 +-----------------|----------|----------------------+
465 DNS protocol: | |
466 ACE | |
467 v v
468 +-------------+ +---------------------+
469 | DNS servers | | Application servers |
470 +-------------+ +---------------------+
472 The box labeled "Application" is where the application splits a domain
473 name into labels, sets the appropriate flags, and performs the ToASCII
474 and ToUnicode operations. This is described in section 4.
476 6.1 Entry and display in applications
478 Applications can accept domain names using any character set or sets
479 desired by the application developer, and can display domain names in
480 any charset. That is, the IDNA protocol does not affect the interface
481 between users and applications.
483 An IDNA-aware application can accept and display internationalized
484 domain names in two formats: the internationalized character set(s)
485 supported by the application, and as an ACE label. ACE labels that are
486 displayed or input MUST always include the ACE prefix. Applications MAY
487 allow input and display of ACE labels, but are not encouraged to do so
488 except as an interface for special purposes, possibly for debugging. ACE
489 encoding is opaque and ugly, and should thus only be exposed to users
490 who absolutely need it. The optional use, especially during a transition
491 period, of ACE encodings in the user interface is described in section
492 6.4. Because name labels encoded as ACE name labels can be rendered
493 either as the encoded ASCII characters or the proper decoded characters,
494 the application MAY have an option for the user to select the preferred
495 method of display; if it does, rendering the ACE SHOULD NOT be the
496 default.
498 Domain names are often stored and transported in many places. For
499 example, they are part of documents such as mail messages and web pages.
500 They are transported in many parts of many protocols, such as both the
501 control commands and the RFC 2822 body parts of SMTP, and the headers
502 and the body content in HTTP. It is important to remember that domain
503 names appear both in domain name slots and in the content that is passed
504 over protocols.
506 In protocols and document formats that define how to handle
507 specification or negotiation of charsets, labels can be encoded in any
508 charset allowed by the protocol or document format. If a protocol or
509 document format only allows one charset, the labels MUST be given in
510 that charset.
512 In any place where a protocol or document format allows transmission of
513 the characters in internationalized labels, internationalized labels
514 SHOULD be transmitted using whatever character encoding and escape
515 mechanism that the protocol or document format uses at that place.
517 All protocols that use domain name slots already have the capacity for
518 handling domain names in the ASCII charset. Thus, ACE labels
519 (internationalized labels that have been processed with the ToASCII
520 operation) can inherently be handled by those protocols.
522 6.2 Applications and resolver libraries
524 Applications normally use functions in the operating system when they
525 resolve DNS queries. Those functions in the operating system are often
526 called "the resolver library", and the applications communicate with the
527 resolver libraries through a programming interface (API).
529 Because these resolver libraries today expect only domain names in
530 ASCII, applications MUST prepare labels that are passed to the resolver
531 library using the ToASCII operation. Labels received from the resolver
532 library contain only ASCII characters; internationalized labels that
533 cannot be represented directly in ASCII use the ACE form. ACE labels
534 always include the ACE prefix.
536 An operating system might have a set of libraries for performing the
537 ToASCII operation. The input to such a library might be in one or more
538 charsets that are used in applications (UTF-8 and UTF-16 are likely
539 candidates for almost any operating system, and script-specific charsets
540 are likely for localized operating systems).
542 IDNA-aware applications MUST be able to work with both
543 non-internationalized labels (those that conform to [STD13] and [STD3])
544 and internationalized labels.
546 It is expected that new versions of the resolver libraries in the future
547 will be able to accept domain names in other formats than ASCII, and
548 application developers might one day pass not only domain names in
549 Unicode, but also in local script to a new API for the resolver
550 libraries in the operating system. Thus the ToASCII and ToUnicode
551 operations might be performed inside these new versions of the resolver
552 libraries.
554 Domain names passed to resolvers or put into the question
555 section of DNS requests follow the rules for "queries" from
556 [STRINGPREP].
558 6.3 DNS servers
560 Domain names stored in zones follow the rules for "stored strings" from
561 [STRINGPREP].
563 For internationalized labels that cannot be represented directly in
564 ASCII, DNS servers MUST use the ACE form produced by the ToASCII
565 operation. All IDNs served by DNS servers MUST contain only ASCII
566 characters.
568 If a signaling system which makes negotiation possible between old and
569 new DNS clients and servers is standardized in the future, the encoding
570 of the query in the DNS protocol itself can be changed from ACE to
571 something else, such as UTF-8. The question whether or not this should
572 be used is, however, a separate problem and is not discussed in this
573 memo.
575 6.4 Avoiding exposing users to the raw ACE encoding
577 Any application that might show the user a domain name obtained from a
578 domain name slot, such as from gethostbyaddr or part of a mail header,
579 will need to be updated if it is to prevent users from seeing the ACE.
581 If an application decodes an ACE name using ToUnicode but cannot show
582 all of the characters in the decoded name, such as if the name contains
583 characters that the output system cannot display, the application SHOULD
584 show the name in ACE format (which always includes the ACE prefix)
585 instead of displaying the name with the replacement character (U+FFFD).
586 This is to make it easier for the user to transfer the name correctly to
587 other programs. Programs that by default show the ACE form when they
588 cannot show all the characters in a name label SHOULD also have a
589 mechanism to show the name that is produced by the ToUnicode operation
590 with as many characters as possible and replacement characters in the
591 positions where characters cannot be displayed.
593 The ToUnicode operation does not alter labels that are not valid ACE
594 labels, even if they begin with the ACE prefix. After ToUnicode has been
595 applied, if a label still begins with the ACE prefix, then it is not a
596 valid ACE label, and is not equivalent to any of the intermediate
597 Unicode strings constructed by ToUnicode.
599 6.5 DNSSEC authentication of IDN domain names
601 DNS Security [DNSSEC] is a method for supplying cryptographic
602 verification information along with DNS messages. Public Key
603 Cryptography is used in conjunction with digital signatures to provide a
604 means for a requester of domain information to authenticate the source
605 of the data. This ensures that it can be traced back to a trusted
606 source, either directly, or via a chain of trust linking the source of
607 the information to the top of the DNS hierarchy.
609 IDNA specifies that all internationalized domain names served by DNS
610 servers that cannot be represented directly in ASCII must use the ACE
611 form produced by the ToASCII operation. This operation must be performed
612 prior to a zone being signed by the private key for that zone. Because
613 of this ordering, it is important to recognize that DNSSEC authenticates
614 the ASCII domain name, not the Unicode form or the mapping between the
615 Unicode form and the ASCII form. In the presence of DNSSEC, this is the
616 name that MUST be signed in the zone and MUST be validated against.
618 One consequence of this for sites deploying IDNA in the presence of
619 DNSSEC is that any special purpose proxies or forwarders used to
620 transform user input into IDNs must be earlier in the resolution flow
621 than DNSSEC authenticating nameservers for DNSSEC to work.
623 6.6 Limitations of IDNA
625 The IDNA protocol does not solve all linguistic issues with users
626 inputting names in different scripts. Many important language-based and
627 script-based mappings are not covered in IDNA and must be handled
628 outside the protocol. For example, names that are entered in a mix of
629 traditional and simplified Chinese characters will not be mapped to a
630 single canonical name. Another example is Scandinavian names that are
631 entered with U+00F6 (LATIN SMALL LETTER O WITH DIAERESIS) will not be
632 mapped to U+00F8 (LATIN SMALL LETTER O WITH STROKE).
634 7. Name server considerations
636 Existing DNS servers do not know the IDNA rules for handling non-ASCII
637 forms of IDNs, and therefore need to be shielded from them. All
638 existing channels through which names can enter a DNS server database
639 (for example, master files [STD13] and DNS update messages [RFC2136])
640 are IDN-unaware because they predate IDNA, and therefore requirement 2
641 of section 3.1 of this document provides the needed shielding, by ensuring
642 that internationalized domain names entering DNS server databases
643 through such channels have already been converted to their equivalent
644 ASCII forms.
646 It is imperative that there be only one ASCII encoding for a particular
647 domain name. Because of the design of the ToASCII and ToUnicode
648 operations, there are no ACE labels that decode to ASCII labels, and
649 therefore name servers cannot contain multiple ASCII encodings of the
650 same domain name.
652 [RFC2181] explicitly allows domain labels to contain octets beyond the
653 ASCII range (0..7F), and this document does not change that. Note,
654 however, that there is no defined interpretation of octets 80..FF as
655 characters. If labels containing these octets are returned to
656 applications, unpredictable behavior could result. The ASCII form
657 defined by ToASCII is the only standard representation for
658 internationalized labels in the current DNS protocol.
660 8. Root server considerations
662 IDNs are likely to be somewhat longer than current domain names, so the
663 bandwidth needed by the root servers is likely to go up by a small amount.
664 Also, queries and responses for IDNs will probably be somewhat longer
665 than typical queries today, so more queries and responses may be forced
666 to go to TCP instead of UDP.
668 9. References
670 9.1 Normative references
672 [PUNYCODE] Adam Costello, "Punycode: An encoding of Unicode for use with
673 IDNA", draft-ietf-idn-punycode.
675 [NAMEPREP] Paul Hoffman and Marc Blanchet, "Nameprep: A Stringprep
676 Profile for Internationalized Domain Names", draft-ietf-idn-nameprep.
678 [STD3] Bob Braden, "Requirements for Internet Hosts -- Communication
679 Layers" (RFC 1122) and "Requirements for Internet Hosts -- Application
680 and Support" (RFC 1123), STD 3, October 1989.
682 [STD13] Paul Mockapetris, "Domain names - concepts and facilities" (RFC
683 1034) and "Domain names - implementation and specification" (RFC 1035),
684 STD 13, November 1987.
686 [STRINGPREP] Paul Hoffman and Marc Blanchet, "Preparation of
687 Internationalized Strings ("stringprep")", draft-hoffman-stringprep,
688 work in progress
690 9.2 Informative references
692 [DNSSEC] Don Eastlake, "Domain Name System Security Extensions", RFC
693 2535, March 1999.
695 [RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
696 Requirement Levels", March 1997, RFC 2119.
698 [RFC2181] Robert Elz and Randy Bush, "Clarifications to the DNS
699 Specification", RFC 2181, July 1997.
701 [UAX9] Unicode Standard Annex #9, The Bidirectional Algorithm,
702 .
704 [UNICODE] The Unicode Consortium. The Unicode Standard, Version 3.2.0 is
705 defined by The Unicode Standard, Version 3.0 (Reading, MA,
706 Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the Unicode
707 Standard Annex #27: Unicode 3.1 (http://www.unicode.org/reports/tr27/)
708 and by the Unicode Standard Annex #28: Unicode 3.2
709 (http://www.unicode.org/reports/tr28/).
711 [USASCII] Vint Cerf, "ASCII format for Network Interchange", October
712 1969, RFC 20.
714 10. Security considerations
716 Security on the Internet partly relies on the DNS. Thus, any change to
717 the characteristics of the DNS can change the security of much of the
718 Internet.
720 This memo describes an algorithm which encodes characters that are not
721 valid according to STD3 and STD13 into octet values that are valid. No
722 security issues such as string length increases or new allowed values
723 are introduced by the encoding process or the use of these encoded
724 values, apart from those introduced by the ACE encoding itself.
726 Domain names are used by users to identify and connect to Internet
727 servers. The security of the Internet is compromised if a user entering
728 a single internationalized name is connected to different servers based
729 on different interpretations of the internationalized domain name.
731 When systems use local character sets other than ASCII and Unicode, this
732 specification leaves the the problem of transcoding between the local
733 character set and Unicode up to the application. If different
734 applications (or different versions of one application) implement
735 different transcoding rules, they could interpret the same name
736 differently and contact different servers. This problem is not solved by
737 security protocols like TLS that do not take local character sets into
738 account.
740 Because this document normatively refers to [NAMEPREP], [PUNYCODE], and
741 [STRINGPREP], it includes the security considerations from those
742 documents as well.
744 If or when this specification is updated to use a more recent Unicode
745 normalization table, the new normalization table will need to be
746 compared with the old to spot backwards incompatible changes. If there
747 are such changes, they will need to be handled somehow, or there will be
748 security as well as operational implications. Methods to handle the
749 conflicts could include keeping the old normalization, or taking care of
750 the conflicting characters by operational means, or some other method.
752 Implementations MUST NOT use more recent normalization tables than the
753 one referenced from this document, even though more recent tables may be
754 provided by operating systems. If an application is unsure of which
755 version of the normalization tables are in the operating system, the
756 application needs to include the normalization tables itself. Using
757 normalization tables other than the one referenced from this
758 specification could have security and operational implications.
760 To help prevent confusion between characters that are visually similar,
761 it is suggested that implementations provide visual indications where a
762 domain name contains multiple scripts. Such mechanisms can also be used
763 to show when a name contains a mixture of simplified and traditional
764 Chinese characters, or to distinguish zero and one from O and l.
766 11. Authors' addresses
768 Patrik Faltstrom
769 Cisco Systems
770 Arstaangsvagen 31 J
771 S-117 43 Stockholm Sweden
772 paf@cisco.com
774 Paul Hoffman
775 Internet Mail Consortium and VPN Consortium
776 127 Segre Place
777 Santa Cruz, CA 95060 USA
778 phoffman@imc.org
780 Adam M. Costello
781 University of California, Berkeley
782 idna-spec.amc @ nicemice.net
784 A. Changes from -10 to -11
786 [[ To be removed when published as an RFC ]]
788 Made capitalization of section titles consistent.
790 In the abstract, changed from:
791 IDNs use characters drawn from a large repertoire (Unicode), but IDNA
792 allows the non-ASCII characters to be represented using the same
793 octets used in so-called host names today. This representation allows
794 IDNs to be introduced with no changes to the existing DNS
795 infrastructure.
796 to:
797 IDNs use characters drawn from a large repertoire (Unicode), but IDNA
798 allows the non-ASCII characters to be represented using only the
799 ASCII characters already allowed in so-called host names today. This
800 backward-compatible representation is required in existing protocols
801 like DNS, so that IDNs can be introduced with no changes to the
802 existing infrastructure.
804 In secton 2, changed from:
805 This document explicitly refers to [STD3] to make it clear where
806 this syntactic restrictions apply.
807 to:
808 This document explicitly cites [STD3] whenever referring to the
809 host name syntax restrictions defined therein.
811 In section 3, added section 3.2 on applicability of IDNA. Also changed
812 the heading numbering for this section, and changed references to the
813 old numbering to reflect the new numbering.
815 In section 4, changed from:
816 3) Decide whether or not to enforce the restrictions on ASCII
817 characters in host names [STD3]. If the restrictions are to be
818 enforced, set the flag called "UseSTD3ASCIIRules".
819 to:
820 3) For each label, decide whether or not to enforce the restrictions
821 on ASCII characters in host names [STD3]. If the restrictions are to
822 be enforced, set the flag called "UseSTD3ASCIIRules" for that label.
824 In section 7, changed the first paragraph from:
825 Because the specification of the DNS database content in [STD13]
826 predates IDNA, DNS database content (such as common zone files) are
827 IDN-unaware, and hence requirement 2 of section 3 of this document
828 applies to them. Internationalized domain names MUST be converted to
829 their equivalent ASCII forms before being entered into DNS database
830 content.
831 to:
832 Existing DNS servers do not know the IDNA rules for handling
833 non-ASCII forms of IDNs, and therefore need to be shielded from them.
834 All existing channels through which names can enter a DNS server
835 database (for example, master files [STD13] and DNS update messages
836 [RFC2136]) are IDN-unaware because they predate IDNA, and therefore
837 requirement 2 of section 3 of this document provides the needed
838 shielding, by ensuring that internationalized domain names entering
839 DNS server databases through such channels have already been
840 converted to their equivalent ASCII forms.