idnits 2.17.1
draft-ietf-idn-idna-08.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.
== 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 719 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.)
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)
-- Obsolete informational reference (is this intentional?): RFC 2535 (ref.
'DNSSEC') (Obsoleted by RFC 4033, RFC 4034, RFC 4035)
Summary: 3 errors (**), 0 flaws (~~), 3 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-08.txt Cisco
3 May 22, 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 the same octets used in so-called host names today.
38 This representation allows IDNs to be introduced with minimal changes to
39 the existing DNS infrastructure. IDNA is only meant for processing
40 domain names, not free text.
42 1. Introduction
44 IDNA works by allowing applications to use certain ASCII name labels
45 (beginning with a special prefix) to represent non-ASCII name labels.
46 Lower-layer protocols need not be aware of this; therefore IDNA does not
47 require changes to any infrastructure. In particular, IDNA does not
48 require any changes to DNS servers, resolvers, or protocol elements,
49 because the ASCII name service provided by the existing DNS is entirely
50 sufficient.
52 This document does not require any applications to conform to IDNA, but
53 applications can elect to use IDNA in order to support IDN while
54 maintaining interoperability with existing infrastructure. Adding IDNA
55 support to an existing application entails changes to the application
56 only, and leaves room for flexibility in the user interface.
58 A great deal of the discussion of IDN solutions has focused on
59 transition issues and how IDN will work in a world where not all of the
60 components have been updated. Proposals that were not chosen by the IDN
61 Working Group would require that user applications, resolvers, and DNS
62 servers be updated in order for a user to use an internationalized
63 domain name. Rather than require widespread updating of all components,
64 IDNA requires only user applications to be updated; no changes are
65 needed to the DNS protocol or any DNS servers or the resolvers on user's
66 computers.
68 1.1 Brief overview for application developers
70 Applications can use IDNA to support internationalized domain names
71 anywhere that ASCII domain names are already supported, including DNS
72 master files and resolver interfaces. (Applications can also define
73 protocols and interfaces that support IDNs directly using non-ASCII
74 representations. IDNA does not prescribe any particular representation
75 for new protocols, but it still defines which names are valid and how
76 they are compared.)
78 The IDNA protocol is contained completely within applications. It is not
79 a client-server or peer-to-peer protocol: everything is done inside the
80 application itself. When used with a DNS resolver library, IDNA is
81 inserted as a "shim" between the application and the resolver library.
82 When used for writing names into a DNS zone, IDNA is used just before
83 the name is committed to the zone.
85 There are two operations described in section 4 of this document:
87 - The ToASCII operation is used before sending an IDN to something that
88 expects ASCII names (such as a resolver) or writing an IDN into a place
89 that expects ASCII names (such as a DNS master file).
91 - The ToUnicode operation is used when displaying names to users, for
92 example names obtained from a DNS zone.
94 It is important to note that the ToASCII operation can fail. If it fails
95 when processing a domain name, that domain name cannot be used as an
96 internationalized domain name and the application has to have some
97 method of dealing with this failure.
99 IDNA requires that implementations process input strings with Nameprep
100 [NAMEPREP], which is a profile of Stringprep [STRINGPREP], and then with
101 Punycode [PUNYCODE]. Implementations of IDNA MUST fully implement
102 Nameprep and Punycode; neither Nameprep nor Punycode are optional.
104 2 Terminology
106 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
107 "MAY" in this document are to be interpreted as described in RFC 2119
108 [RFC2119].
110 A code point is an integral value associated with a character in a coded
111 character set.
113 Unicode [UNICODE] is a coded character set containing tens of thousands
114 of characters. A single Unicode code point is denoted by "U+" followed
115 by four to six hexadecimal digits, while a range of Unicode code points
116 is denoted by two hexadecimal numbers separated by "..", with no
117 prefixes.
119 ASCII means US-ASCII [USASCII], a coded character set containing 128
120 characters associated with code points in the range 0..7F. Unicode is an
121 extension of ASCII: it includes all the ASCII characters and associates
122 them with the same code points.
124 The term "LDH code points" is defined in this document to mean the code
125 points associated with ASCII letters, digits, and the hyphen-minus; that
126 is, U+002D, 30..39, 41..5A, and 61..7A. "LDH" is an abbreviation for
127 "letters, digits, hyphen".
129 [STD13] talks about "domain names" and "host names", but many people use
130 the terms interchangeably. Further, because [STD13] was not terribly
131 clear, many people who are sure they know the exact definitions of each
132 of these terms disagree on the definitions. In this document the term
133 "domain name" is used in general. When referring explicitly to the
134 syntax restrictions for host names in [STD3], the term "host name
135 syntax" is used.
137 A label is an individual part of a domain name. Labels are usually shown
138 separated by dots; for example, the domain name "www.example.com" is
139 composed of three labels: "www", "example", and "com". (The zero-length
140 root label described in [STD13], which can be explicit as in
141 "www.example.com." or implicit as in "www.example.com", is not
142 considered a label in this specification.) Throughout this document the
143 term "label" is shorthand for "text label", and "every label" means
144 "every text label". In IDNA, not all text strings can be labels.
146 An "internationalized domain name" (IDN) is a domain name for which the
147 ToASCII operation (see section 4) can be applied to each label without
148 failing. This document does not attempt to define an "internationalized
149 host name". It is expected that some name-handling bodies, such as large
150 zone administrators and groups of affiliated zone administrators, will
151 want to limit the characters allowed in IDNs further than what is
152 specified in this document, such as to prohibit additional characters
153 that they feel are unneeded or harmful in registered domain names.
155 In IDNA, equivalence of labels is defined in terms of the ToASCII
156 operation, which constructs an ASCII form for a given label. Labels are
157 defined to be equivalent if and only if their ASCII forms produced by
158 ToASCII match using a case-insensitive ASCII comparison. Traditional
159 ASCII labels already have a notion of equivalence: upper case and lower
160 case are considered equivalent. The IDNA notion of equivalence is an
161 extension of the old notion. Equivalent labels in IDNA are treated as
162 alternate forms of the same label, just as "foo" and "Foo" are treated
163 as alternate forms of the same label.
165 An "internationalized label" is a label composed of characters from the
166 Unicode character set; note, however, that not every string of Unicode
167 characters can be an internationalized label.
169 To allow internationalized labels to be handled by existing
170 applications, IDNA uses an "ACE label" (ACE stands for ASCII Compatible
171 Encoding), which can be represented using only ASCII characters but is
172 equivalent to a label containing non-ASCII characters. More rigorously,
173 an ACE label is defined to be any label that the ToUnicode operation
174 would alter. For every internationalized label that cannot be directly
175 represented in ASCII, there is an equivalent ACE label. An ACE label
176 always begins with the ACE prefix defined in section 5. The conversion
177 of labels to and from the ACE form is specified in section 4.
179 The "ACE prefix" is defined in this document to be a string of ASCII
180 characters that appears at the beginning of every ACE label. It is
181 specified in section 5.
183 A "domain name slot" is defined in this document to be a protocol
184 element or a operation argument or a return value (and so on) explicitly
185 designated for carrying a domain name. Examples of domain name slots
186 include: the QNAME field of a DNS query; the name argument of the
187 gethostbyname() library function; the part of an email address following
188 the at-sign (@) in the From: field of an email message header; and the
189 host portion of the URI in the src attribute of an HTML tag.
190 General text that just happens to contain a domain name is not a domain
191 name slot; for example, a domain name appearing in the plain text body
192 of an email message is not occupying a domain name slot.
194 An "IDN-aware domain name slot" is defined in this document to be a
195 domain name slot explicitly designated for carrying an internationalized
196 domain name as defined in this document. The designation may be static
197 (for example, in the specification of the protocol or interface) or
198 dynamic (for example, as a result of negotiation in an interactive
199 session).
201 An "IDN-unaware domain name slot" is defined in this document to be any
202 domain name slot that is not an IDN-aware domain name slot. Obviously,
203 this includes any domain name slot whose specification predates IDNA.
205 3. Requirements
207 IDNA conformance means adherence to the following four requirements:
209 1) Whenever dots are used as label separators, the following characters
210 MUST be recognized as dots: U+002E (full stop), U+3002 (ideographic full
211 stop), U+FF0E (fullwidth full stop), U+FF61 (halfwidth ideographic full
212 stop).
214 2) Whenever a domain name is put into an IDN-unaware domain name slot
215 (see section 2), it MUST contain only ASCII characters, and, if dots are
216 used as label separators, changing all the label separators to U+002E.
217 Given an internationalized domain name (IDN), an equivalent domain name
218 satisfying this requirement can be obtained by applying the ToASCII
219 operation (see section 4) to each label.
221 3) ACE labels obtained from domain name slots SHOULD be hidden from
222 users except when the use of the non-ASCII form would cause problems or
223 when the ACE form is explicitly requested. Given an internationalized
224 domain name, an equivalent domain name containing no ACE labels can be
225 obtained by applying the ToUnicode operation (see section 4) to each
226 label. When requirements 2 and 3 both apply, requirement 1 takes
227 precedence.
229 4) Whenever two labels are compared, they MUST be considered to match if
230 and only if they are equivalent, that is, their ASCII forms (obtained by
231 applying ToASCII) match using a case-insensitive ASCII comparison.
232 Whenever two names are compared, they MUST be considered to match if and
233 only if their corresponding labels match, regardless of whether the
234 names use the same forms of label separators.
236 4. Conversion operations
238 An application converts a domain name put into an IDN-unaware slot or
239 displayed to a user. This section specifies the steps to perform in the
240 conversion, and the ToASCII and ToUnicode operations.
242 The input to ToASCII or ToUnicode is a single label that is a sequence
243 of Unicode code points (remember that all ASCII code points are also
244 Unicode code points). If a domain name is represented using a character
245 set other than Unicode or US-ASCII, it will first need to be transcoded
246 to Unicode.
248 Starting from a whole domain name, the steps that an application takes
249 to do the conversions are:
251 1) Decide whether the domain name is a "stored string" or a "query
252 string" as described in [STRINGPREP]. If this conversion follows the
253 "queries" rule from [STRINGPREP], set the flag called "AllowUnassigned".
255 2) Split the domain name into individual labels as described in section
256 3. The labels do not include the separator.
258 3) Decide whether or not to enforce the restrictions on ASCII characters
259 in host names [STD3]. If the restrictions are to be enforced, set the
260 flag called "UseSTD3ASCIIRules".
262 4) Process each label with either the ToASCII or the ToUnicode
263 operation. Use the ToASCII operation/function if you are about to put
264 the name into an IDN-unaware slot. Use the ToUnicode operation if you
265 are displaying the name to a user.
267 5) If ToASCII was applied in step 4 and dots are used as label
268 separators, change all the label separators to U+002E (full stop).
270 The following two subsections define the ToASCII and ToUnicode
271 operations that are used in step 4.
273 4.1 ToASCII
275 The ToASCII operation takes a sequence of Unicode code points that make
276 up one label and transforms it into a sequence of code points in the
277 ASCII range (0..7F). If ToASCII succeeds, the original sequence and the
278 resulting sequence are equivalent labels.
280 It is important to note that the ToASCII operation can fail. If the
281 ToASCII operation fails on any label in a domain name, that domain name
282 MUST NOT be used as an internationalized domain name. The application
283 needs to have some method of dealing with this failure.
285 The inputs to ToASCII are a sequence of code points; the AllowUnassigned
286 flag; and the UseSTD3ASCIIRules flag. The output of ToASCII is either a
287 sequence of ASCII code points or a failure condition.
289 ToASCII never alters a sequence of code points that are all in the ASCII
290 range to begin with (although it could fail). Applying the ToASCII
291 operation multiple times has exactly the same effect as applying it just
292 once.
294 ToASCII consists of the following steps:
296 1. If all code points in the sequence are in the ASCII range (0..7F)
297 then skip to step 3.
299 2. Perform the steps specified in [NAMEPREP] and fail if there is
300 an error. The AllowUnassigned flag is used in [NAMEPREP].
302 3. If the UseSTD3ASCIIRules flag is set, then perform these checks:
304 (a) Verify the absence of non-LDH ASCII code points; that is,
305 the absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.
307 (b) Verify the absence of leading and trailing hyphen-minus;
308 that is, the absence of U+002D at the beginning and end of
309 the sequence.
311 4. If all code points in the sequence are in the ASCII range
312 (0..7F), then skip to step 8.
314 5. Verify that the sequence does NOT begin with the ACE prefix.
316 6. Encode the sequence using the encoding algorithm in [PUNYCODE]
317 and fail if there is an error.
319 7. Prepend the ACE prefix.
321 8. Verify that the number of code points is in the range 1 to 63
322 inclusive.
324 4.2 ToUnicode
326 The ToUnicode operation takes a sequence of Unicode code points that
327 make up one label and returns a sequence of Unicode code points. If the
328 input sequence is a label in ACE form, then the result is an equivalent
329 internationalized label that is not in ACE form, otherwise the original
330 sequence is returned unaltered.
332 ToUnicode never fails. If any step fails, then the original input
333 sequence is returned immediately in that step.
335 The inputs to ToUnicode are a sequence of code points; the
336 AllowUnassigned flag; and the UseSTD3ASCIIRules flag. The output of
337 ToUnicode is always a sequence of Unicode code points.
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 an
343 error. (If step 3 of ToASCII is also performed here, it will not
344 affect the overall behavior of ToUnicode, but it is not
345 necessary.) The AllowUnassigned flag is used in [NAMEPREP].
347 3. Verify that the sequence begins with the ACE prefix, and save a
348 copy of the sequence.
350 4. Remove the ACE prefix.
352 5. Decode the sequence using the decoding algorithm in [PUNYCODE]
353 and fail if there is an error. Save a copy of the result of
354 this step.
356 6. Apply ToASCII.
358 7. Verify that the result of step 6 matches the saved copy from
359 step 3, using a case-insensitive ASCII comparison.
361 8. Return the saved copy from step 5.
363 5. ACE prefix
365 [[ Note to the IESG and Internet Draft readers: The two uses of the
366 string "IESG--" below are to be changed at time of publication to a
367 prefix which fulfills the requirements in the first paragraph. IANA will
368 assign this value. ]]
370 The ACE prefix, used in the conversion operations (section 4), is two
371 alphanumeric ASCII characters followed by two hyphen-minuses. It cannot
372 be any of the prefixes already used in earlier documents, which includes
373 the following: "bl--", "bq--", "dq--", "lq--", "mq--", "ra--", "wq--"
374 and "zq--". The ToASCII and ToUnicode operations MUST recognize the ACE
375 prefix in a case-insensitive manner.
377 The ACE prefix for IDNA is "IESG--".
379 This means that an ACE label might be "IESG--de-jg4avhby1noc0d", where
380 "de-jg4avhby1noc0d" is the part of the ACE label that is generated by
381 the encoding steps in [PUNYCODE].
383 While all ACE labels begin with the ACE prefix, not all labels beginning
384 with the ACE prefix are necessarily ACE labels. Non-ACE labels that
385 begin with the ACE prefix will confuse users and SHOULD NOT be allowed
386 in DNS zones.
388 6. Implications for typical applications using DNS
390 In IDNA, applications perform the processing needed to input
391 internationalized domain names from users, display internationalized
392 domain names to users, and process the inputs and outputs from DNS and
393 other protocols that carry domain names.
395 The components and interfaces between them can be represented
396 pictorially as:
398 +------+
399 | User |
400 +------+
401 ^
402 | Input and display: local interface methods
403 | (pen, keyboard, glowing phosphorus, ...)
404 +-------------------|-------------------------------+
405 | v |
406 | +-----------------------------+ |
407 | | Application | |
408 | | (ToASCII and ToUnicode | |
409 | | operations may be | |
410 | | called here) | |
411 | +-----------------------------+ |
412 | ^ ^ | End system
413 | | | |
414 | Call to resolver: | | Application-specific |
415 | ACE | | protocol: |
416 | v | ACE unless the |
417 | +----------+ | protocol is updated |
418 | | Resolver | | to handle other |
419 | +----------+ | encodings |
420 | ^ | |
421 +-----------------|----------|----------------------+
422 DNS protocol: | |
423 ACE | |
424 v v
425 +-------------+ +---------------------+
426 | DNS servers | | Application servers |
427 +-------------+ +---------------------+
429 The box labeled "Application" is where the application splits a host
430 name into labels, sets the appropriate flags, and performs the ToASCII
431 and ToUnicode operations. This is described in section 4.
433 6.1 Entry and display in applications
435 Applications can accept domain names using any character set or sets
436 desired by the application developer, and can display domain names in
437 any charset. That is, the IDNA protocol does not affect the interface
438 between users and applications.
440 An IDNA-aware application can accept and display internationalized
441 domain names in two formats: the internationalized character set(s)
442 supported by the application, and as an ACE label. ACE labels that are
443 displayed or input MUST always include the ACE prefix. Applications MAY
444 allow input and display of ACE labels, but are not encouraged to do so
445 except as an interface for special purposes, possibly for debugging. ACE
446 encoding is opaque and ugly, and should thus only be exposed to users
447 who absolutely need it. The optional use, especially during a transition
448 period, of ACE encodings in the user interface is described in section
449 6.4. Because name labels encoded as ACE name labels can be rendered
450 either as the encoded ASCII characters or the proper decoded characters,
451 the application MAY have an option for the user to select the preferred
452 method of display; if it does, rendering the ACE SHOULD NOT be the
453 default.
455 Domain names are often stored and transported in many places. For
456 example, they are part of documents such as mail messages and web pages.
457 They are transported in many parts of many protocols, such as both the
458 control commands and the RFC 2822 body parts of SMTP, and the headers
459 and the body content in HTTP. It is important to remember that domain
460 names appear both in domain name slots and in the content that is passed
461 over protocols.
463 In protocols and document formats that define how to handle
464 specification or negotiation of charsets, labels can be encoded in any
465 charset allowed by the protocol or document format. If a protocol or
466 document format only allows one charset, the labels MUST be given in
467 that charset.
469 In any place where a protocol or document format allows transmission of
470 the characters in internationalized labels, internationalized labels
471 SHOULD be transmitted using whatever character encoding and escape
472 mechanism that the protocol or document format uses at that place.
474 All protocols that use domain name slots already have the capacity for
475 handling domain names in the ASCII charset. Thus, ACE labels
476 (internationalized labels that have been processed with the ToASCII
477 operation) can inherently be handled by those protocols.
479 6.2 Applications and resolver libraries
481 Applications normally use functions in the operating system when they
482 resolve DNS queries. Those functions in the operating system are often
483 called "the resolver library", and the applications communicate with the
484 resolver libraries through a programming interface (API).
486 Because these resolver libraries today expect only domain names in
487 ASCII, applications MUST prepare labels that are passed to the resolver
488 library using the ToASCII operation. Labels received from the resolver
489 library contain only ASCII characters; internationalized labels that
490 cannot be represented directly in ASCII use the ACE form. ACE labels
491 always include the ACE prefix.
493 IDNA-aware applications MUST be able to work with both
494 non-internationalized labels (those that conform to [STD13] and [STD3])
495 and internationalized labels.
497 It is expected that new versions of the resolver libraries in the future
498 will be able to accept domain names in other formats than ASCII, and
499 application developers might one day pass not only domain names in
500 Unicode, but also in local script to a new API for the resolver
501 libraries in the operating system. Thus the ToASCII and ToUnicode
502 operations might be performed inside these new versions of the resolver
503 libraries.
505 Domain names stored in zones follow the rules for "stored strings" from
506 [STRINGPREP]. DNS requests follow the rules for "queries" from
507 [STRINGPREP].
509 6.3 DNS servers
511 An operating system might have a set of libraries for performing the
512 ToASCII operation. The input to such a library might be in one or more
513 charsets that are used in applications (UTF-8 and UTF-16 are likely
514 candidates for almost any operating system, and script-specific charsets
515 are likely for localized operating systems).
517 For internationalized labels that cannot be represented directly in
518 ASCII, DNS servers MUST use the ACE form produced by the ToASCII
519 operation. All IDNs served by DNS servers MUST contain only ASCII
520 characters.
522 If a signaling system which makes negotiation possible between old and
523 new DNS clients and servers is standardized in the future, the encoding
524 of the query in the DNS protocol itself can be changed from ACE to
525 something else, such as UTF-8. The question whether or not this should
526 be used is, however, a separate problem and is not discussed in this
527 memo.
529 6.4 Avoiding exposing users to the raw ACE encoding
531 All applications that might show the user a domain name obtained from a
532 domain name slot, such as from gethostbyaddr or part of a mail header,
533 SHOULD be updated as soon as possible in order to prevent users from
534 seeing the ACE.
536 If an application decodes an ACE name using ToUnicode but cannot show
537 all of the characters in the decoded name, such as if the name contains
538 characters that the output system cannot display, the application SHOULD
539 show the name in ACE format (which always includes the ACE prefix)
540 instead of displaying the name with the replacement character (U+FFFD).
541 This is to make it easier for the user to transfer the name correctly to
542 other programs. Programs that by default show the ACE form when they
543 cannot show all the characters in a name label SHOULD also have a
544 mechanism to show the name that is produced by the ToUnicode operation
545 with as many characters as possible and replacement characters in the
546 positions where characters cannot be displayed.
548 The ToUnicode operation does not alter labels that are not valid ACE
549 labels, even if they begin with the ACE prefix. After ToUnicode has been
550 applied, if a label still begins with the ACE prefix, then it is not a
551 valid ACE label, and is not equivalent to any of the intermediate
552 Unicode strings constructed by ToUnicode.
554 6.5 Bidirectional text in domain names
556 The display of domain names that contain bidirectional text is not
557 covered in this document. It may be covered in a future version of this
558 document, or may be covered in a different document.
560 For developers interested in displaying domain names that have
561 bidirectional text, the Unicode standard has an extensive discussion of
562 how to deal with reorder glyphs for display when dealing with
563 bidirectional text such as Arabic or Hebrew. See [UAX9] for more
564 information. In particular, all Unicode text is stored in logical order.
566 6.6 DNSSEC authentication of IDN domain names
568 DNS Security [DNSSEC] is a method for supplying cryptographic
569 verification information along with DNS messages. Public Key
570 Cryptography is used in conjunction with digital signatures to provide a
571 means for a requester of domain information to authenticate the source
572 of the data. This ensures that it can be traced back to a trusted
573 source, either directly, or via a chain of trust linking the source of
574 the information to the top of the DNS hierarchy.
576 IDNA specifies that all internationalized domain names served by DNS
577 servers that cannot be represented directly in ASCII must use the ACE
578 form produced by the ToASCII operation. This operation must be performed
579 prior to a zone being signed by the private key for that zone. Because
580 of this ordering, it is important to recognize that DNSSEC authenticates
581 the ASCII domain name, not the Unicode form or the mapping between the
582 Unicode form and the ASCII form. In other words, the output of ToASCII
583 is the canonical name. In the presence of DNSSEC, this is the name that
584 MUST be signed in the zone and MUST be validated against.
586 One consequence of this for sites deploying IDNA in the presence of
587 DNSSEC is that any special purpose proxies or forwarders used to
588 transform user input into IDNs must be earlier in the resolution flow
589 than DNSSEC authenticating nameservers for DNSSEC to work.
591 6.7 Limitations of IDNA
593 The IDNA protocol does not solve all linguistic issues with users
594 inputting names in different scripts. Many important language-based and
595 script-based mappings are not covered in IDNA and must be handled
596 outside the protocol. For example, names that are entered in a mix of
597 traditional and simplified Chinese characters will not be mapped to a
598 single canonical name. Another example is Scandinavian names that are
599 entered with U+00F6 (LATIN SMALL LETTER O WITH DIAERESIS) will not be
600 mapped to U+00F8 (LATIN SMALL LETTER O WITH STROKE).
602 7. Name Server Considerations
604 Internationalized domain name data in zone files (as specified by
605 section 5 of RFC 1035) MUST be processed with ToASCII before it is
606 entered in the zone files.
608 It is imperative that there be only one ASCII encoding for a particular
609 domain name. Thus, a primary master name server MUST NOT contain an
610 ACE-encoded label that decodes to an ASCII label. The ToASCII operation
611 assures that no such names are ever output from the operation.
613 Name servers MUST NOT serve records with domain names that contain
614 non-ASCII characters; such names MUST be converted to ACE form by the
615 ToASCII operation in order to be served. If names that are not processed
616 by ToASCII are passed to an application, it will result in unpredictable
617 behavior. Note that [STRINGPREP] describes how to handle versioning of
618 unallocated codepoints.
620 8. Root Server Considerations
622 IDNs are likely to be somewhat longer than current host names, so the
623 bandwidth needed by the root servers should go up by a small amount.
624 Also, queries and responses for IDNs will probably be somewhat longer
625 than typical queries today, so more queries and responses may be forced
626 to go to TCP instead of UDP.
628 9. References
630 9.1 Normative references
632 [PUNYCODE] Adam Costello, "Punycode: An encoding of Unicode for use with
633 IDNA", draft-ietf-idn-punycode.
635 [NAMEPREP] Paul Hoffman and Marc Blanchet, "Nameprep: A Stringprep
636 Profile for Internationalized Domain Names", draft-ietf-idn-nameprep.
638 [STD3] Bob Braden, "Requirements for Internet Hosts -- Communication
639 Layers" (RFC 1122) and "Requirements for Internet Hosts -- Application
640 and Support" (RFC 1123), STD 3, October 1989.
642 [STD13] Paul Mockapetris, "Domain names - concepts and facilities" (RFC
643 1034) and "Domain names - implementation and specification" (RFC 1035),
644 STD 13, November 1987.
646 [STRINGPREP] Paul Hoffman and Marc Blanchet, "Preparation of
647 Internationalized Strings ("stringprep")", draft-hoffman-stringprep,
648 work in progress
650 9.2 Informative references
652 [DNSSEC] Don Eastlake, "Domain Name System Security Extensions", RFC
653 2535, March 1999.
655 [RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
656 Requirement Levels", March 1997, RFC 2119.
658 [UAX9] Unicode Standard Annex #9, The Bidirectional Algorithm,
659 .
661 [UNICODE] The Unicode Standard, Version 3.1.0: The Unicode Consortium.
662 The Unicode Standard, Version 3.0. Reading, MA, Addison-Wesley
663 Developers Press, 2000. ISBN 0-201-61633-5, as amended by: Unicode
664 Standard Annex #27: Unicode 3.1,
665 .
667 [USASCII] Vint Cerf, "ASCII format for Network Interchange", October
668 1969, RFC 20.
670 10. Security Considerations
672 Security on the Internet partly relies on the DNS. Thus, any change to
673 the characteristics of the DNS can change the security of much of the
674 Internet.
676 This memo describes an algorithm which encodes characters that are not
677 valid according to STD3 and STD13 into octet values that are valid. No
678 security issues such as string length increases or new allowed values
679 are introduced by the encoding process or the use of these encoded
680 values, apart from those introduced by the ACE encoding itself.
682 Domain names are used by users to connect to Internet servers. The
683 security of the Internet would be compromised if a user entering a
684 single internationalized name could be connected to different servers
685 based on different interpretations of the internationalized domain name.
687 Because this document normatively refers to [NAMEPREP], it includes the
688 security considerations from that document as well.
690 11. Authors' Addresses
692 Patrik Faltstrom
693 Cisco Systems
694 Arstaangsvagen 31 J
695 S-117 43 Stockholm Sweden
696 paf@cisco.com
698 Paul Hoffman
699 Internet Mail Consortium and VPN Consortium
700 127 Segre Place
701 Santa Cruz, CA 95060 USA
702 phoffman@imc.org
704 Adam M. Costello
705 University of California, Berkeley
706 idna-spec.amc @ nicemice.net