idnits 2.17.1
draft-ietf-idn-idna-06.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 588 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 12 instances of too long lines in the document, the longest
one being 4 characters in excess of 72.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 145: '...label MUST contain only ASCII characte...'
RFC 2119 keyword, line 150: '...2) ACE labels SHOULD be hidden from us...'
RFC 2119 keyword, line 156: '...e compared, they MUST be considered to...'
RFC 2119 keyword, line 251: '...icode operations MUST recognize the AC...'
RFC 2119 keyword, line 309: '...CE label. Applications MAY allow input...'
(14 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
-- 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 section? 'RFC2119' on line 506 looks like a reference
-- Missing reference section? 'UNICODE' on line 520 looks like a reference
-- Missing reference section? 'STD13' on line 513 looks like a reference
-- Missing reference section? 'NAMEPREP' on line 503 looks like a reference
-- Missing reference section? 'PUNYCODE' on line 498 looks like a reference
-- Missing reference section? 'STD3' on line 509 looks like a reference
-- Missing reference section? 'UAX9' on line 517 looks like a reference
-- Missing reference section? 'DNSSEC' on line 500 looks like a reference
Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 10 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-06.txt Cisco
3 January 7, 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 hostnames today.
39 1. Introduction
41 IDNA works by allowing applications to use certain ASCII name labels
42 (beginning with a special prefix) to represent non-ASCII name labels.
43 Lower-layer protocols need not be aware of this; therefore IDNA does not
44 require changes to any infrastructure. In particular, IDNA does not
45 require any changes to DNS servers, resolvers, or protocol elements,
46 because the ASCII name service provided by the existing DNS is entirely
47 sufficient.
49 This document does not require any applications to conform to IDNA,
50 but applications can elect to use IDNA in order to support IDN while
51 maintaining interoperability with existing infrastructure. Adding IDNA
52 support to an existing application entails changes to the application
53 only, and leaves room for flexibility in the user interface.
55 A great deal of the discussion of IDN solutions has focused on
56 transition issues and how IDN will work in a world where not all of the
57 components have been updated. Other proposals would require that user
58 applications, resolvers, and DNS servers be updated in order for a user
59 to use an internationalized host name. Rather than require widespread
60 updating of all components, IDNA requires only user applications to be
61 updated; no changes are needed to the DNS protocol or any DNS servers or
62 the resolvers on user's computers.
64 This document is being discussed on the ietf-idna@mail.apps.ietf.org
65 mailing list. To subscribe, send a message to
66 ietf-idna-request@mail.apps.ietf.org with the single word "subscribe" in
67 the body of the message.
69 2 Terminology
71 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
72 "MAY" in this document are to be interpreted as described in RFC 2119
73 [RFC2119].
75 A code point is an integral value associated with a character in a coded
76 character set.
78 Unicode [UNICODE] is a coded character set containing tens of thousands
79 of characters. A single Unicode code point is denoted by "U+" followed
80 by four to six hexadecimal digits, while a range of Unicode code points
81 is denoted by two hexadecimal numbers separated by "..", with no
82 prefixes.
84 ASCII means US-ASCII, a coded character set containing 128 characters
85 associated with code points in the range 0..7F. Unicode is an extension
86 of ASCII: it includes all the ASCII characters and associates them with
87 the same code points.
89 The term "LDH code points" is defined in this document to mean the code
90 points associated with ASCII letters, digits, and the hyphen-minus; that
91 is, U+002D, 30..39, 41..5A, and 61..7A. "LDH" is an abbreviation for
92 "letters, digits, hyphen".
94 A label is an individual part of a domain name. Labels are usually shown
95 separated by dots; for example, the domain name "www.example.com" is
96 composed of three labels: "www", "example", and "com". In IDNA, not all
97 text strings can be labels. (The zero-length root label that is implied
98 in domain names, as described in [STD13], is not considered a label in
99 this specification.)
101 An "internationalized domain name" (IDN) is a domain name for which the
102 ToASCII operation (see section 4) can be applied to each label without
103 failing.
105 An internationalized label contains characters from the Unicode
106 character set. To allow such a label to be handled by existing
107 applications, an "ACE label" is defined to be a label that contains only
108 ASCII characters but represents an equivalent label containing non-ASCII
109 characters. For every internationalized label that cannot be directly
110 represented in ASCII, there is an equivalent ACE label. The conversion
111 of labels to and from the ACE form is specified in section 4.
113 The "ACE prefix" is defined in this document to be a string of ASCII
114 characters that appears at the beginning of every ACE label. It is
115 specified in section 5.
117 A "domain name slot" is defined in this document to be a protocol element
118 or a function argument or a return value (and so on) explicitly
119 designated for carrying a domain name. Examples of domain name slots
120 include: the QNAME field of a DNS query; the name argument of the
121 gethostbyname() library function; the part of an email address following
122 the at-sign (@) in the From: field of an email message header; and the host
123 portion of the URI in the src attribute of an HTML tag.
124 General text that just happens to contain a domain name is not a domain name
125 slot; for example, a domain name appearing in the plain text body of an
126 email message is not occupying a domain name slot.
128 An "internationalized domain name slot" is defined in this document to
129 be a domain name slot explicitly designated for carrying an
130 internationalized domain name as defined in this document. The
131 designation may be static (for example, in the specification of the
132 protocol or interface) or dynamic (for example, as a result of
133 negotiation in an interactive session).
135 A "generic domain name slot" is defined in this document to be any
136 domain name slot that is not an internationalized domain name slot.
137 Obviously, this includes any domain name slot whose specification
138 predates IDNA.
140 3. Requirements
142 IDNA conformance means adherence of the following three rules:
144 1) Whenever a domain name is put into a generic domain name slot, every
145 label MUST contain only ASCII characters. Given an internationalized
146 domain name (IDN), an equivalent domain name satisfying this requirement
147 can be obtained by applying the ToASCII operation (see section 4)
148 to each label.
150 2) ACE labels SHOULD be hidden from users whenever possible. Therefore,
151 before a domain name is displayed to a user or is output into a context
152 likely to be viewed by users, the ToUnicode operation (see section 4)
153 SHOULD be applied to each label. When requirements 1 and 2 both apply,
154 requirement 1 takes precedence.
156 3) Whenever two labels are compared, they MUST be considered to
157 match if and only if their ASCII forms (obtained by applying ToASCII)
158 match using a case-insensitive ASCII comparison.
160 4. Conversion operations
162 This section specifies the ToASCII and ToUnicode operations. Each one
163 operates on a sequence of Unicode code points (but remember that all
164 ASCII code points are also Unicode code points). When domain names are
165 represented using character sets other than Unicode and ASCII, they will
166 need to first be transcoded to Unicode before these operations can be
167 applied, and might need to be transcoded back afterwards.
169 4.1 ToASCII
171 The ToASCII operation takes a sequence of Unicode code points and
172 transforms it into a sequence of code points in the ASCII range (0..7F).
173 The original sequence and the resulting sequence are equivalent labels
174 (if the original is an internationalized label that cannot be directly
175 represented in ASCII, the result will be the equivalent ACE label).
177 ToASCII fails if any step of it fails. Failure means that the original
178 sequence cannot be used as a label in an IDN.
180 ToASCII never alters a sequence of code points that are all in the ASCII
181 range to begin with (although it may fail).
183 ToASCII consists of the following steps:
185 1. If all code points in the sequence are in the ASCII range (0..7F)
186 then skip to step 3.
188 2. Perform the steps specified in [NAMEPREP].
190 3. Host-specific restrictions: If the label is part of a host name
191 (or is subject to host name syntax rules) then perform these
192 checks:
194 * Verify the absence of non-LDH ASCII code points; that is, the
195 absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.
197 * Verify the absence of leading and trailing hyphen-minus; that
198 is, the absence of U+002D at the beginning and end of the
199 sequence.
201 4. If all code points in the sequence are in the ASCII range (0..7F),
202 then skip to step 8.
204 5. Verify that the sequence does NOT begin with the ACE prefix.
206 6. Encode the sequence using the encoding algorithm in [PUNYCODE].
208 7. Prepend the ACE prefix.
210 8. Verify that the number of code points is in the range 1 to 63
211 inclusive.
213 4.2 ToUnicode
215 The ToUnicode operation takes a sequence of Unicode code points and
216 returns a sequence of Unicode code points. If the input sequence is a
217 label in ACE form, then the result is an equivalent internationalized
218 label that is not in ACE form, otherwise the original sequence is
219 returned unaltered.
221 ToUnicode never fails. If any step fails, then the original input
222 sequence is returned immediately in that step.
224 1. If all code points in the sequence are in the ASCII range (0..7F)
225 then skip to step 3.
227 2. Perform the steps specified in [NAMEPREP]. (If step 3
228 of ToASCII is also performed here, it will not affect the
229 overall behavior of ToUnicode, but it is not necessary.)
231 3. Verify that the sequence begins with the ACE prefix, and save a
232 copy of the sequence.
234 4. Remove the ACE prefix.
236 5. Decode the sequence using decoding algorithm in [PUNYCODE]. Save
237 a copy of the result of this step.
239 6. Apply ToASCII.
241 7. Verify that the sequence matches the saved copy from step 3, using
242 a case-insensitive ASCII comparison.
244 8. Return the saved copy from step 5.
246 5. ACE prefix
248 The ACE prefix, used in the conversion operations (section 4), will be
249 specified in a future revision of this document. It will be two
250 alphanumeric ASCII characters followed by two hyphen-minuses. The
251 ToASCII and ToUnicode operations MUST recognize the ACE prefix in a
252 case-insensitive manner.
254 For example, the eventual ACE prefix might be the string "jk--". In this
255 case, an ACE label might be "jk--r3c2a-qc902xs", where "r3c2a-qc902xs"
256 is the part of the ACE label that is generated by the encoding steps in
257 [PUNYCODE].
259 6. Implications for typical applications using DNS
261 In IDNA, applications perform the processing needed to input
262 internationalized domain names from users, display internationalized
263 domain names to users, and process the inputs and outputs from DNS and
264 other protocols that carry domain names.
266 The components and interfaces between them can be represented
267 pictorially as:
269 +------+
270 | User |
271 +------+
272 ^
273 | Input and display: local interface methods
274 | (pen, keyboard, glowing phosphorus, ...)
275 +-------------------|-------------------------------+
276 | v |
277 | +-----------------------------+ |
278 | | Application | |
279 | | (conversion between local | |
280 | | character set and Unicode | |
281 | | is done here) | |
282 | +-----------------------------+ |
283 | ^ ^ | End system
284 | | | |
285 | Call to resolver: | | Application-specific |
286 | ACE | | protocol: |
287 | v | predefined by the |
288 | +----------+ | protocol or defaults |
289 | | Resolver | | to ACE |
290 | +----------+ | |
291 | ^ | |
292 +-----------------|----------|----------------------+
293 DNS protocol: | |
294 ACE | |
295 v v
296 +-------------+ +---------------------+
297 | DNS servers | | Application servers |
298 +-------------+ +---------------------+
300 6.1 Entry and display in applications
302 Applications can accept domain names using any character set or sets
303 desired by the application developer, and can display domain names in any
304 charset. That is, the IDNA protocol does not affect the interface
305 between users and applications.
307 An IDNA-aware application can accept and display internationalized domain
308 names in two formats: the internationalized character set(s) supported
309 by the application, and as an ACE label. Applications MAY allow input
310 and display of ACE labels, but are not encouraged to do so except as an
311 interface for special purposes, possibly for debugging. ACE encoding is
312 opaque and ugly, and should thus only be exposed to users who absolutely
313 need it. The optional use, especially during a transition period, of ACE
314 encodings in the user interface is described in section 6.4. Because
315 name labels encoded as ACE name labels can be rendered either as the
316 encoded ASCII characters or the proper decoded characters, the
317 application MAY have an option for the user to select the preferred
318 method of display; if it does, rendering the ACE SHOULD NOT be the
319 default.
321 Domain names are often stored and transported in many places. For example,
322 they are part of documents such as mail messages and web pages. They are
323 transported in many parts of many protocols, such as both the
324 control commands and the RFC 2822 body parts of SMTP, and the headers
325 and the body content in HTTP. It is important to remember that domain
326 names appear both in domain name slots and in the content that is passed
327 over protocols.
329 In protocols and document formats that define how to handle
330 specification or negotiation of charsets, labels can be encoded in any
331 charset allowed by the protocol or document format. If a protocol or
332 document format only allows one charset, the labels MUST be given in
333 that charset.
335 In any place where a protocol or document format allows transmission of
336 the characters in internationalized labels, internationalized labels
337 SHOULD be transmitted using whatever character encoding and escape
338 mechanism that the protocol or document format uses at that place.
340 All protocols that use domain name slots already have the capacity for
341 handling domain names in the ASCII charset. Thus, ACE labels
342 (internationalized labels that have been processed with the ToASCII
343 operation) can inherently be handled by those protocols.
345 6.2 Applications and resolver libraries
347 Applications normally use functions in the operating system when they
348 resolve DNS queries. Those functions in the operating system are often
349 called "the resolver library", and the applications communicate with the
350 resolver libraries through a programming interface (API).
352 Because these resolver libraries today expect only domain names in
353 ASCII, applications MUST prepare labels that are passed to the resolver
354 library using the ToASCII operation. Labels received from the resolver
355 library contain only ASCII characters; internationalized labels that
356 cannot be represented directly in ASCII use the ACE form.
358 IDNA-aware applications MUST be able to work with both
359 non-internationalized labels (those that conform to [STD13]
360 and [STD3]) and internationalized labels.
362 It is expected that new versions of the resolver libraries in the future
363 will be able to accept domain names in other formats than ASCII, and
364 application developers might one day pass not only domain names in
365 Unicode, but also in local script to a new API for the resolver
366 libraries in the operating system.
368 6.3 DNS servers
370 An operating system might have a set of libraries for performing the
371 ToASCII operation. The input to such a library might be in one or more
372 charsets that are used in applications (UTF-8 and UTF-16 are likely
373 candidates for almost any operating system, and script-specific charsets
374 are likely for localized operating systems).
376 For internationalized labels that cannot be represented directly in
377 ASCII, DNS servers MUST use the ACE form produced by the ToASCII
378 operation. All IDNs served by DNS servers MUST contain only ASCII
379 characters.
381 If a signalling system which makes negotiation possible between old and
382 new DNS clients and servers is standardized in the future, the encoding
383 of the query in the DNS protocol itself can be changed from ACE to
384 something else, such as UTF-8. The question whether or not this should
385 be used is, however, a separate problem and is not discussed in this
386 memo.
388 6.4 Avoiding exposing users to the raw ACE encoding
390 All applications that might show the user a domain name obtained from a
391 domain name slot, such as from gethostbyaddr or part of a mail header,
392 SHOULD be updated as soon as possible in order to prevent users from
393 seeing the ACE.
395 If an application decodes an ACE name using ToUnicode but cannot show
396 all of the characters in the decoded name, such as if the name contains
397 characters that the output system cannot display, the application SHOULD
398 show the name in ACE format instead of displaying the name with the
399 replacement character (U+FFFD). This is to make it easier for the user
400 to transfer the name correctly to other programs. Programs that by
401 default show the ACE form when they cannot show all the characters in a
402 name label SHOULD also have a mechanism to show the name that is
403 produced by the ToUnicode operation with as many characters as possible
404 and replacement characters in the positions where characters cannot be
405 displayed.
407 The ToUnicode operation does not alter labels that are not valid ACE
408 labels, even if they begin with the ACE prefix. After ToUnicode has been
409 applied, if a label still begins with the ACE prefix, then it is not a
410 valid ACE label, and is not equivalent to any of the intermediate
411 Unicode strings constructed by ToUnicode.
413 6.5 Bidirectional text in domain names
415 The display of domain names that contain bidirectional text is not covered
416 in this document. It may be covered in a future version of this
417 document, or may be covered in a different document.
419 For developers interested in displaying host names that have
420 bidirectional text, the Unicode standard has an extensive discussion of
421 how to deal with reorder glyphs for display when dealing with
422 bidirectional text such as Arabic or Hebrew. See [UAX9] for more
423 information. In particular, all Unicode text is stored in logical order.
425 6.6 DNSSEC authentication of IDN domain names
427 DNS Security [DNSSEC] is a method for supplying cryptographic
428 verification information along with DNS messages. Public Key
429 Cryptography is used in conjunction with digital signatures to provide a
430 means for a requester of domain information to authenticate the source
431 of the data. This ensures that it can be traced back to a trusted
432 source, either directly, or via a chain of trust linking the source of
433 the information to the top of the DNS hierarchy.
435 IDNA specifies that all internationalized domain names served by DNS
436 servers that cannot be represented directly in ASCII must use the ACE
437 form produced by the ToASCII operation. This operation must be performed
438 prior to a zone being signed by the private key for that zone. Because
439 of this ordering, it is important to recognize that DNSSEC authenticates
440 the ASCII domain name, not the Unicode form or the mapping between the
441 Unicode form and the ASCII form. In other words, the output of ToASCII
442 is the canonical name. In the presence of DNSSEC, this is the name that
443 MUST be signed in the zone and MUST be validated against. It also SHOULD
444 be used for other name comparisons, such as when a browser wants to
445 indicate that a URL has been previously visited.
447 One consequence of this for sites deploying IDNA in the presence of
448 DNSSEC is that any special purpose proxies or forwarders used to
449 transform user input into IDNs must be earlier in the resolution flow
450 than DNSSEC authenticating nameservers for DNSSEC to work.
452 7. Name Server Considerations
454 Internationalized domain name data in zone files (as specified by section
455 5 of RFC 1035) MUST be processed with ToASCII before it is entered in
456 the zone files.
458 It is imperative that there be only one ASCII encoding for a particular
459 domain name. ACE is an encoding for domain name labels that use non-ASCII
460 characters. Thus, a primary master name server MUST NOT contain an
461 ACE-encoded label that decodes to an ASCII label. The ToASCII operation
462 assures that no such names are ever output from the operation.
464 Name servers MUST NOT serve records with domain names that contain
465 non-ASCII characters; such names MUST be converted to ACE form by the
466 ToASCII operation in order to be served. If names that are not processed
467 by ToASCII are passed to an application, it will result in unpredictable
468 behavior. Note that [NAMEPREP] describes how to handle versioning of
469 unallocated codepoints.
471 8. Root Server Considerations
473 Because there are no changes to the DNS protocols, adopting this
474 protocol has no effect on the DNS root servers.
476 9. Security Considerations
478 Much of the security of the Internet relies on the DNS. Thus, any change
479 to the characteristics of the DNS can change the security of much of the
480 Internet.
482 This memo describes an algorithm which encodes characters that are not
483 valid according to STD3 and STD13 into octet values that are valid. No
484 security issues such as string length increases or new allowed values
485 are introduced by the encoding process or the use of these encoded
486 values, apart from those introduced by the ACE encoding itself.
488 Domain names are used by users to connect to Internet servers. The
489 security of the Internet would be compromised if a user entering a
490 single internationalized name could be connected to different servers
491 based on different interpretations of the internationalized domain name.
493 Because this document normatively refers to [NAMEPREP], it includes the
494 security considerations from that document as well.
496 A. References
498 [PUNYCODE] Adam Costello, "Punycode", draft-ietf-idn-punycode.
500 [DNSSEC] Don Eastlake, "Domain Name System Security Extensions", RFC
501 2535, March 1999.
503 [NAMEPREP] Paul Hoffman and Marc Blanchet, "Preparation of
504 Internationalized Host Names", draft-ietf-idn-nameprep.
506 [RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
507 Requirement Levels", March 1997, RFC 2119.
509 [STD3] Bob Braden, "Requirements for Internet Hosts -- Communication
510 Layers" (RFC 1122) and "Requirements for Internet Hosts -- Application
511 and Support" (RFC 1123), STD 3, October 1989.
513 [STD13] Paul Mockapetris, "Domain names - concepts and facilities" (RFC
514 1034) and "Domain names - implementation and specification" (RFC 1035,
515 STD 13, November 1987.
517 [UAX9] Unicode Standard Annex #9, The Bidirectional Algorithm.
518 http://www.unicode.org/unicode/reports/tr9/
520 [UNICODE] The Unicode Standard, Version 3.1.0: The Unicode Consortium.
521 The Unicode Standard, Version 3.0. Reading, MA, Addison-Wesley
522 Developers Press, 2000. ISBN 0-201-61633-5, as amended by: Unicode
523 Standard Annex #27: Unicode 3.1
524 .
526 B. Design philosophy
528 Many proposals for IDN protocols have required that DNS servers be
529 updated to handle internationalized domain names. Because of this, a
530 person who wanted to use an internationalized domain name would have to be
531 sure that their request went to a DNS server that had been updated for
532 IDN. Further, that server could send queries only to other servers that
533 had been updated for IDN, because the queries contain new protocol
534 elements to differentiate IDN labels from current labels. In
535 addition, these proposals require that resolvers be updated to use the
536 new protocols, and in most cases the applications would need to be
537 updated as well.
539 These proposals would require changes to the application protocols that
540 use host names as protocol elements, because of the assumptions and
541 requirements made in those protocols about the characters that have
542 always been used for host names, and the encoding of those characters.
543 Other proposals for IDN protocols do not require changes to DNS servers
544 but still require changes to most application protocols to handle the
545 new names.
547 Updating all (or even a significant percentage) of the existing servers
548 in the world will be difficult, to say the least. Updating applications,
549 application gateways, and clients to handle changes to the application
550 protocols is also daunting. Because of this, we have designed a protocol
551 that requires no updating of any name servers. IDNA still requires the
552 updating of applications, but only for input and display of names, not
553 for changes to the protocols. Once users have updated the applications,
554 they can immediately start using internationalized host names. The cost
555 of implementing IDN may thus be much lower, and the speed of
556 implementation could be much higher.
558 C. Authors' Addresses
560 Patrik Faltstrom
561 Cisco Systems
562 Arstaangsvagen 31 J
563 S-117 43 Stockholm Sweden
564 paf@cisco.com
566 Paul Hoffman
567 Internet Mail Consortium and VPN Consortium
568 127 Segre Place
569 Santa Cruz, CA 95060 USA
570 phoffman@imc.org
572 Adam M. Costello
573 University of California, Berkeley
574 idna-spec.amc @ nicemice.net