idnits 2.17.1 draft-ietf-idn-requirements-02.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: ---------------------------------------------------------------------------- ** 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 9 longer pages, the longest (page 1) being 59 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.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 405 has weird spacing: '...ng must be lo...' == Line 442 has weird spacing: '...not add new c...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Oct 2000) is 8586 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'URI' is mentioned on line 105, but not defined == Missing Reference: 'URN' is mentioned on line 105, but not defined -- Looks like a reference, but probably isn't: '1' on line 267 -- Looks like a reference, but probably isn't: '2' on line 273 -- Looks like a reference, but probably isn't: '3' on line 277 -- Looks like a reference, but probably isn't: '4' on line 284 -- Looks like a reference, but probably isn't: '5' on line 292 -- Looks like a reference, but probably isn't: '6' on line 300 -- Looks like a reference, but probably isn't: '7' on line 304 -- Looks like a reference, but probably isn't: '8' on line 308 -- Looks like a reference, but probably isn't: '9' on line 312 -- Looks like a reference, but probably isn't: '10' on line 319 -- Looks like a reference, but probably isn't: '11' on line 325 -- Looks like a reference, but probably isn't: '12' on line 330 -- Looks like a reference, but probably isn't: '13' on line 340 -- Looks like a reference, but probably isn't: '14' on line 345 -- Looks like a reference, but probably isn't: '15' on line 349 -- Looks like a reference, but probably isn't: '16' on line 354 -- Looks like a reference, but probably isn't: '17' on line 359 -- Looks like a reference, but probably isn't: '18' on line 367 -- Looks like a reference, but probably isn't: '19' on line 371 -- Looks like a reference, but probably isn't: '20' on line 375 -- Looks like a reference, but probably isn't: '21' on line 383 -- Looks like a reference, but probably isn't: '22' on line 387 -- Looks like a reference, but probably isn't: '23' on line 395 -- Looks like a reference, but probably isn't: '24' on line 398 == Missing Reference: 'UTR-21' is mentioned on line 401, but not defined -- Looks like a reference, but probably isn't: '25' on line 405 -- Looks like a reference, but probably isn't: '26' on line 410 -- Looks like a reference, but probably isn't: '27' on line 414 -- Looks like a reference, but probably isn't: '28' on line 418 -- Looks like a reference, but probably isn't: '29' on line 422 -- Looks like a reference, but probably isn't: '30' on line 425 -- Looks like a reference, but probably isn't: '31' on line 428 -- Looks like a reference, but probably isn't: '32' on line 434 -- Looks like a reference, but probably isn't: '33' on line 436 -- Looks like a reference, but probably isn't: '34' on line 442 -- Looks like a reference, but probably isn't: '35' on line 446 -- Looks like a reference, but probably isn't: '36' on line 456 -- Looks like a reference, but probably isn't: '37' on line 463 -- Looks like a reference, but probably isn't: '38' on line 466 -- Looks like a reference, but probably isn't: '39' on line 469 -- Looks like a reference, but probably isn't: '40' on line 473 == Unused Reference: 'DNSEXT' is defined on line 761, but no explicit reference was found in the text == Unused Reference: 'UTR15' is defined on line 809, but no explicit reference was found in the text == Unused Reference: 'UTR21' is defined on line 813, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CHARREQ' -- Possible downref: Non-RFC (?) normative reference: ref. 'DNSEXT' ** Obsolete normative reference: RFC 1766 (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2553 (Obsoleted by RFC 3493) ** Downref: Normative reference to an Informational draft: draft-iab-unique-dns-root (ref. 'UNIROOT') ** Downref: Normative reference to an Informational RFC: RFC 2825 (ref. 'IABIDN') -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' -- Possible downref: Non-RFC (?) normative reference: ref. 'US-ASCII' -- Possible downref: Non-RFC (?) normative reference: ref. 'UTR15' -- Possible downref: Non-RFC (?) normative reference: ref. 'UTR21' Summary: 12 errors (**), 0 flaws (~~), 11 warnings (==), 49 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF IDN Working Group Editors Zita Wenzel, James Seng 2 Internet Draft draft-ietf-idn-requirements-02.txt 3 12th May 2000 Expires 12rd Oct 2000 5 Requirements of Internationalized Domain Names 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as 15 Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as 21 "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes the requirement for encoding international 32 characters into DNS names and records. This document is guidance for 33 developing protocols for internationalized domain names. 35 1. Introduction 37 At present, the encoding of Internet domain names is restricted to a 38 subset of 7-bit ASCII (ISO/IEC 646). HTML, XML, IMAP, FTP, and many 39 other text based items on the Internet have already been at least 40 partially internationalized. It is important for domain names to be 41 similarly internationalized or for an equivalent solution to be found. 42 This document assumes that the most effective solution involves putting 43 non-ASCII names inside some parts of the overall DNS system. 45 This document is being discussed on the "idn" mailing list. To join the 46 list, send a message to with the words 47 "subscribe idn" in the body of the message. Archives of the mailing 48 list can also be found at ftp://ops.ietf.org/pub/lists/idn*. 50 1.1 Definitions and Conventions 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in [RFC2119]. 56 Characters mentioned in this document are identified by their position 58 Expires 12th of October 2000 [Page 1] 59 in the Unicode [UNICODE] character set. The notation U+12AB, for 60 example, indicates the character at position 12AB (hexadecimal) in the 61 Unicode character set. Note that the use of this notation is not an 62 indication of a requirement to use Unicode. 64 Examples quoted in this document should be considered as a method to 65 further explain the meanings and principles adopted by the document. It 66 is not a requirement for the protocol to satisfy the examples. 68 A character is a member of a set of elements used for organization, 69 control, or representation of data. 71 A coded character is a character with its coded representation. 73 A coded character set ("CCS") is a set of unambiguous rules that 74 establishes a character set and the relationship between the characters 75 of the set and their coded representation. 77 A graphic character or glyph is a character, other than a control 78 function, that has a visual representation normally handwritten, 79 printed, or displayed. 81 A character encoding scheme or "CES" is a mapping from one or more 82 coded character sets to a set of octets. Some CESs are associated with 83 a single CCS; for example, UTF-8 [RFC2279] applies only to ISO 10646. 84 Other CESs, such as ISO 2022, are associated with many CCSs. 86 A charset is a method of mapping a sequence of octets to a sequence of 87 abstract characters. A charset is, in effect, a combination of one or 88 more CCS with a CES. Charset names are registered by the IANA according 89 to procedures documented in RFC 2278. 91 A language is a way that humans interact. In written form, a language 92 is expressed in characters. The same set of characters can often be 93 used in many languages, and many languages can be expressed using 94 different scripts. A particular charset may have different glyphs 95 (shapes) depending on the language being used. 97 1.2 Description of the Domain Name System 99 The Domain Name System is defined by [RFC1034] and [RFC1035], with 100 clarifications, extensions and modifications given in [RFC1123], 101 [RFC1996], [RFC2181] and others. Of special importance here is the 102 security extensions described in [RFC2535] and companions. 104 Over the years, many different words have been used to describe the 105 components of resource naming on the Internet [URI], [URN], ...; to make 106 certain that the set of terms used in this document are well-defined and 107 non-ambiguous, the definitions are given here. 109 A master server for a zone holds the main copy of that zone. This copy 110 is sometimes stored in a zone file. A slave server for a zone holds a 111 complete copy of the records for that zone. Slave servers may be either 112 authorized by the zone owner (secondary servers) or unauthorized 114 Expires 12th of October 2000 [Page 2] 115 (so-called "stealth secondaries"). Master and authorized slave servers 116 are listed in the NS records for the zone, and are termed 117 "authoritative" servers. In many contexts, outside this document the 118 term "primary" is used interchangeably with "master" and "secondary" is 119 used interchangeably with "slave". 121 A caching server holds temporary copies of DNS records; it uses records 122 to answer queries about domain names. Further explanation of these terms 123 can be found in [RFC1034] and [RFC1996]. 125 DNS names can be represented in multiple forms, with different 126 properties for internationalization. The most important ones are: 128 - Domain name: The binary representation of a name used internally in 129 the DNS protocol. This consists of a series of components of 1-63 130 octets, with an overall length limited to 255 octets (including the 131 length fields). 132 - Master file format domain name: This is a representation of the name 133 as a sequence of characters in some character sets; the common 134 convention (derived from [RFC1035] section 5.1) is to represent the 135 octets of the name as ASCII characters where the octet is in the set 136 corresponding to the ASCII values for [a-zA-Z0-9-], using an escape 137 mechanism (\x or \NNN) where not, and separating the components of the 138 name by the dot character ("."). 140 The form specified for most protocols using the DNS is a limited form of 141 the master file format domain name. This limited form is defined in 142 [RFC1034] Section 3.5 and [RFC1123]. In most implementations of 143 applications today, domain names in the Internet have been limited to 144 the much more restricted forms used, e.g., in email. Those names are 145 limited to the ASCII upper and lower-case characters (interpreted in a 146 case-independent fashion), the digits, and the hyphen, with the further 147 restrictions that a name may not consist entirely of digits and that a 148 hyphen cannot occur at the beginning or end of a component or following 149 another hyphen. 151 1.3 Definition of "hostname" and "Internationalized Domain Name" 153 In the DNS protocols, a name is referred to as a sequence of octets. 154 However, when discussing requirements for internationalized domain 155 names, what we are looking for is ways to represent characters, 156 something meaningful for humans. 158 In this document, this is referred to as a "hostname". While this term 159 has been used for many different purposes over the years, it is used 160 here in the sense of "sequence of characters (not octets) representing a 161 domain name conforming to the limited hostname syntax". 163 This document attempts to define the requirements for an 164 "Internationalized Domain Name" (IDN). This is defined as a sequence of 165 characters that can be used in the context of functions where a hostname 166 is used today, but contains one or more characters that are outside the 167 set of characters specified as legal characters for host names. 169 Expires 12th of October 2000 [Page 3] 170 1.4 A multilayer model of the DNS function 172 The DNS can be seen as a multilayer function: 174 - The bottom layer is where the packets passed across the Net in a DNS 175 query and a DNS response. At this level, what matters is the format 176 and meaning of bits and octets in a DNS packet. 177 - Above that is the "DNS service", created by an infrastructure of DNS 178 servers, NS records that point to those DNS servers, and is pointed to 179 by the root servers (listed in the "root cache file" on each DNS 180 server, often called "named.cache". It is at this level that the 181 statement "the DNS has a single root" [UNIROOT] makes sense, but 182 still, what are being transferred are octets, not characters. 183 - Interfacing to the user is a service layer, often called "the resolver 184 library", and often embedded in the operating system or system 185 libraries of the client machines. It is at the top of this layer that 186 the API calls commonly known as "gethostbyname" and "gethostbyaddress" 187 reside. These calls are modified to support IPv6 [RFC2553]. A 188 conceptually similar layer exists in authoritative DNS servers, 189 comprising the parts that generate "meaningful" strings in DNS files. 190 Due to the popularity of the "master file" format, this layer often 191 exists only in the administrative routines of the service maintainers. 192 - The user of this layer (resolver library) is the application programs 193 that use the DNS, such as mailers, mail servers, Web clients, Web 194 servers, Web caches, IRC clients, FTP clients, distributed file 195 systems, distributed databases, and almost all other applications on 196 TCP/IP. (preference not fact) 198 Graphically, one can illustrate it like this: 200 +---------------+ +---------------------+ 201 | Application | | (Base data) | 202 +---------------+ +---------------------+ 203 | Application service interface | 204 | For ex. GethostbyXXXX interface | (no standard) 205 +---------------+ +---------------------+ 206 | Resolver | | Auth DNS server | 207 +---------------+ +---------------------+ 208 | <----- DNS service interface -----> | 209 +------------------------------------------------------------------+ 210 | DNS service | 211 | +-----------------------+ +--------------------+ | 212 | | Forwarding DNS server | | Caching DNS server | | 213 | +-----------------------+ +--------------------+ | 214 | | 215 | +-------------------------+ | 216 | | Parent-zone DNS servers | | 217 | +-------------------------+ | 218 | | 219 | +-------------------------+ | 220 | | Root DNS servers | | 221 | +-------------------------+ | 222 | | 223 +------------------------------------------------------------------+ 225 Expires 12th of October 2000 [Page 4] 226 1.5 Service model of the DNS 227 The Domain Name Service is used for multiple purposes, each of which is 228 characterized by what it puts into the system (the query) and what it 229 expects as a result (the reply). 230 The most used ones in the current DNS are: 232 - Hostname-to-address service (A, AAAA, A6): Enter a hostname, and get 233 back an IPv4 or IPv6 address. 234 Hostname-to-Mail server service (MX): As above, but the expected 235 return value is a hostname and a priority, for smtp servers. 236 - Address-to-hostname service (PTR): Enter an IPv4 or IPv6 address (in 237 in-addr.arpa or ip6.int form respectively) and get back a hostname. 238 - Domain delegation service (NS). Enter a domain name and get back 239 nameserver records (designated hosts who provides authoritive 240 nameservice) for the domain. 242 New services are being defined, either as entirely new services (IPv6 to 243 hostname mapping using binary labels) or as embellishments to other 244 services (DNSSEC returning information about whether a given DNS service 245 is performed securely or not). 247 These services exist, conceptually, at the Application/Resolver 248 interface, NOT at the DNS-service interface. This document attempts to 249 set requirements for an equivalent of the "used services" given above, 250 where "hostname" is replaced by "Internationalized Domain Name". This 251 doesn't preclude the fact that IDN should work will any kind of DNS 252 queries. IDN is a new service, since existing protocols like SMTP or 253 HTTP use the old service. it is a matter of great concern how the new 254 and old services work together, and how other protocols can take 255 advantage of the new service. 256 2. General Requirements 257 These requirements address two concerns: The service offered to the 258 users (the application service), and the protocol extensions, if needed, 259 added to support this service. 261 In the requirements, we attempt to use the term "service" whenever a 262 requirement concerns the service, and "protocol" whenever a requirement 263 is believed to constrain the possible implementation. 265 2.1 Compatibility and Interoperability 267 [1] The DNS is essential to the entire Internet. Therefore, the service 268 must not damage present DNS protocol interoperability. It must make the 269 minimum number of changes to existing protocols on all layers of the 270 stack. It must continue to allow any system anywhere to resolve any 271 internationalized domain name. 273 [2] The service must preserve the basic concept and facilities of domain 274 names as described in [RFC1034]. It must maintain a single, global, 275 universal and consistent hierarchical namespace. 277 [3] The same name resolution request must generate the same response, 278 regardless of the location or localization settings in the resolver, in 280 Expires 12th of October 2000 [Page 5] 281 the master server, and in any slave servers involved in the resolution 282 process. 284 [4] If the service allows more than one charset, the protocol should 285 also allow creation of caching servers that do not understand the 286 charset in which a request or response is encoded. Such caching servers 287 should work as well for IDNs as they do for current domain names. The 288 caching server performs correctly if it gives essentially the same 289 answer (without the authoritative bit) as the master server would have 290 if presented with the same request. 292 [5] A caching server must not return data in response to a query that 293 would not have been returned if the same query had been presented to an 294 authoritative server. This applies fully for the cases when: 296 - The caching server does not know about IDN 297 - The caching server implements the whole specification 298 - The caching server implements a valid subset of the specification 300 [6] The service should be able to be upgraded at any time with new 301 features and retain backwards compatibility with the current 302 specification. 304 [7] The service may modify the DNS protocol [RFC1035] and other related 305 work undertaken by the DNSEXT WG. However, these changes should be as 306 small as possible and any changes must be approved by the DNSEXT WG. 308 [8] The protocol supporting the service should be as simple as possible 309 from the user's perspective. Ideally, users should not realize that IDN 310 was added on to the existing DNS. 312 [9] A fall-back strategy or mechanism based upon ASCII may be needed 313 during a transition period during deployment and adoption of IDN. 314 Therefore, if an encoding is not mapped into ASCII, then there might be 315 an ASCII-only representation compatible with the current DNS and there 316 should be a way for a program to find the ASCII-only representation for 317 IDN. This is depending on how the protocol will handle exceptions. 319 [10] The best solution is one that maintains maximum feasible 320 compatibility with current DNS standards as long as it meets the other 321 requirements in this document. 323 2.2 Internationalization 325 [11] Internationalized characters must be allowed to be represented and 326 used in DNS names and records. The protocol must specify what charset is 327 used when resolving domain names and how characters are encoded in DNS 328 records. 330 [12] This document does not recommend any charset for IDN. If more than 331 one charset is used, or might be used in future, in the protocol, then 332 the protocol must specify all the charsets being used and for what 333 purpose. It must also conform to [RFC1766] by tagging the charset. No 334 implicit rules should be allowed for multiple charsets. A CCS(s) chosen 336 Expires 12th of October 2000 [Page 6] 337 must at least cover the range of characters as currently defined (and as 338 being added) by ISO 10646/Unicode. 340 [13] CES(s) chosen should not encode ASCII characters differently 341 depending on the other characters in the string. In other words, unless 342 IDN names are identified and coded differently from ASCII-only ones, 343 characters in the ASCII set should remain as specified in [US-ASCII]. 345 [14] The protocol should not invent a new CCS for the purpose of IDN 346 only and should use existing CES. The charset(s) chosen should also be 347 non-ambiguous. 349 [15] The protocol should not make any assumptions about the location in 350 a domain name where internationalization might appear. In other words, 351 it should not differentiate between any part of a domain name because 352 this may impose restrictions on future internationalization efforts. 354 [16] The protocol should also not make any localized restrictions in the 355 protocol. For example, an IDN implementation which only allows domain 356 names to use a single local script would immediately restrict 357 multinational organization. 359 [17] Because of the wide range of devices that use the DNS and the wide 360 range of characteristics of international scripts, the service might 361 need to allow more than one method of domain name input and display. 362 However, there must be a single way of encoding an internationalized 363 domain name within the core of the DNS. 365 2.3 Localization 367 [18] The service should be able to handle localized requirements of 368 different languages. For example, IDN must be able to handle 369 bi-directional writing for scripts such as Arabic. 371 [19] Historically, "." has been the separator of labels in the host 372 names. The service should not use different separators for different 373 languages. 375 [20] Most of the localization work could be handled by the user 376 interface. It should not matter how the domain names are input or 377 presented, such as in a reverse order or bi-directional, or with the 378 introduction of a new separator. However, the final wire format must be 379 in canonical order. 381 2.4 Canonicalization 383 [21] Matching rules are a complicated process for IDN. Canonicalization 384 of characters must follow precise and predictable rules to ensure 385 consistency. [CHARREQ] is a recommended as a guide on canonicalization. 387 [22] The DNS has to match a host name in a request with a host name held 388 in one or more zones. It also needs to sort names into order. It is 389 expected that some sort of canonicalization algorithm will be used as 390 the first step of this process. This section discusses some of the 392 Expires 12th of October 2000 [Page 7] 393 properties which will be required of that algorithm. 395 [23] The canonicalization algorithm might specify operations for case, 396 ligature, and punctuation folding. 398 [24] In order to retain backwards compatibility with the current DNS, 399 the service must retain the case-insensitive comparison for US-ASCII as 400 specified in [RFC1035]. For example, Latin capital letter A (U+0041) 401 must match Latin small letter a (U+0061). [UTR-21] describes some of 402 the issues with case mapping. Case-insensitivity for non US-ASCII has to 403 be discussed in the protocol proposal. 405 [25] Case folding must be locale independent. For example, Latin 406 capital letter I (U+0049) case folded to lower case in the Turkish 407 context will become Latin small letter dotless i (U+0131). But in the 408 English context, it will become Latin small letter i (U+0069). 410 [26] If other canonicalization is done, then it must be done before the 411 domain name is resolved. Further, the canonicalization must be easily 412 upgradable as new languages and writing systems are added. 414 [27] Any conversion (case, ligature folding, punctuation folding, ...) 415 from what the user enters into a client to what the client asks for 416 resolution must be done identically on any request from any client. 418 [28] If the protocol specifies a canonicalization algorithm, a caching 419 server should perform correctly regardless of how much (or how little) 420 of that algorithm it has implemented. [1 request to remove] 422 [29] If the protocol requires a canonicalization algorithm, all requests 423 sent to a caching server must already be in the canonical form. 425 [30] If the charset can be normalized, then it should be normalized 426 before it is used in IDN. (conflict) 428 [31] The protocol should avoid inventing a new normalization form 429 provided a technically sufficient one is available (such as in an ISO 430 standard). 432 2.5 Operational Issues 434 [32] Zone files should remain easily editable. 436 [33] An IDN-capable resolver or server shall not generate more traffic 437 than a non-IDN-capable resolver or server would when resolving an 438 ASCII-only domain name. The amount of traffic generated when resolving 439 an IDN shall be similar to that generated when resolving an ASCII-only 440 name. 442 [34] The service should not add new centralized administration for the 443 DNS. A domain administrator should be able to create internationalized 444 names as easily as adding current domain names. 446 [35] Within a single zone, the zone manager must be able to define 448 Expires 12th of October 2000 [Page 8] 449 equivalence rules that suit the purpose of the zone, such as, but not 450 limited to, and not necessarily, non-ASCII case folding, Unicode 451 normalizations (if Unicode is chosen), Cyrillic/Greek/Latin folding, or 452 traditional/simplified Chinese equivalence. Such defined equivalences 453 must not remove equivalences that are assumed by (old or 454 local-rule-ignorant) caches. 456 [36] The character set of a signed zone file should be the same as the 457 character set of the unsigned zone file. The protocol must allow offline 458 DNSSEC signing. It should be possible to look at the 459 signed file and see that it is the same as the unsigned one. 461 2.6 Others 463 [37] The service may provide the same DNS resources using 464 internationalized text as it currently provides using ASCII text. 466 [38] To get full semantics for IDN, an upgrade of the DNS and related 467 software may be needed. 469 [39] The protocol should consider new features of DNS such as DNSSEC and 470 DNAME. For example, DNAME might be useful to simplify canonicalization 471 for IDN. 473 [40] The protocol must work for IPv4 and IPv6. 475 3. Technical Analysis 477 There are many standard protocols and RFCs which depend on 478 domain names and have make various assumptions about the characters 479 in them always conforming to [RFC1034] and the other restriction 480 discussed above (see [IABIDN]). We expect that the protocols 481 listed below to be affected: 483 I RFC2813 Internet Relay Chat : Server Protocol 484 I RFC2805 Media Gateway Control Protocol Architecture and Requirements 485 S RFC2789 Mail Monitoring MIB 486 S RFC2782 A DNS RR for specifying the location of services (DNS SRV) 487 I RFC2775 Internet Transparency 488 I RFC2772 6Bone Backbone Routing Guidelines 489 I RFC2768 Network Policy and Services: A Report of a Workshop on 490 Middleware 491 I RFC2767 Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS) 492 S RFC2766 Network Address Translation - Protocol Translation (NAT-PT) 493 S RFC2765 Stateless IP/ICMP Translation Algorithm (SIIT) 494 I RFC2763 Dynamic Hostname Exchange Mechanism for IS-IS 495 E RFC2756 Hyper Text Caching Protocol (HTCP/0.0) 496 S RFC2748 The COPS (Common Open Policy Service) Protocol 497 S RFC2744 Generic Security Service API Version 2 : C-bindings 498 S RFC2743 Generic Security Service Application Program Interface 499 I RFC2705 Media Gateway Control Protocol (MGCP) Version 1.0 500 I RFC2694 DNS extensions to Network Address Translators (DNS_ALG) 501 E RFC2693 SPKI Certificate Theory 502 S RFC2673 Binary Labels in the Domain Name System 504 Expires 12th of October 2000 [Page 9] 505 S RFC2672 Non-Terminal DNS Name Redirection 506 S RFC2671 Extension Mechanisms for DNS (EDNS0) 507 I RFC2663 IP Network Address Translator (NAT) Terminology and 508 Considerations 509 S RFC2661 Layer Two Tunneling Protocol "L2TP" 510 E RFC2654 A Tagged Index Object for use in the Common Indexing Protocol 511 I RFC2637 Point-to-Point Tunneling Protocol (PPTP) 512 I RFC2636 Wireless Device Configuration (OTASP/OTAPA) via ACAP 513 S RFC2632 S/MIME Version 3 Certificate Handling 514 S RFC2622 Routing Policy Specification Language (RPSL) 515 S RFC1616 Hypertext Transfer Protocol -- HTTP/1.1 516 I RFC2614 An API for Service Location 517 S RFC2609 Service Templates and Service: Schemes 518 B RFC2606 Reserved Top Level DNS Names 519 I RFC2604 Wireless Device Configuration (OTASP/OTAPA) via ACAP 520 S RFC2600 Internet Official Protocol Standards 521 S RFC2595 Using TLS with IMAP, POP3 and ACAP 522 I RFC2553 Basic Socket Interface Extensions for IPv6 523 I RFC2546 6Bone Routing Practice 524 S RFC2543 SIP: Session Initiation Protocol 525 I RFC2541 DNS Security Operational Considerations 526 E RFC2540 Detached Domain Name System (DNS) Information 527 S RFC2539 Storage of Diffie-Hellman Keys in the Domain Name System (DNS) 528 S RFC2538 Storing Certificates in the Domain Name System (DNS) 529 S RFC2537 RSA/MD5 KEYs and SIGs in the Domain Name System (DNS) 530 S RFC2546 DSA KEYs and SIGs in the Domain Name System (DNS) 531 S RFC2535 Domain Name System Security Extensions 532 I RFC2517 Building Directories from DNS: Experiences from WWWSeeker 533 S RFC2511 Internet X.509 Certificate Request Message Format 534 B RFC2505 Anti-Spam Recommendations for SMTP MTAs 535 S RFC2500 Internet Official Protocol Standards 536 S RFC2486 The Network Access Identifier 537 S RFC2459 Internet X.509 Public Key Infrastructure Certificate and CRL 538 Profile 539 S RFC2421 Voice Profile for Internet Mail - version 2 540 I RFC2412 The OAKLEY Key Determination Protocol 541 S RFC2408 Internet Security Association and Key Management Protocol 542 (ISAKMP) 543 S RFC2407 The Internet IP Security Domain of Interpretation for ISAKMP 544 S RFC2401 Security Architecture for the Internet Protocol 545 S RFC2400 INTERNET OFFICIAL PROTOCOL STANDARDS 546 S RFC2396 Uniform Resource Identifiers (URI): Generic Syntax 547 I RFC2377 Naming Plan for Internet Directory-Enabled Applications 548 I RFC2367 "PF_KEY Key Management API, Version 2" 549 I RFC2353 APPN/HPR in IP Networks APPN Implementers' Workshop Closed 550 Pages Document 551 E RFC2345 Domain Names and Company Name Retrieval 552 S RFC2326 Real Time Streaming Protocol (RTSP) 553 B RFC2317 Classless IN-ADDR.ARPA delegation 554 S RFC2308 Negative Caching of DNS Queries (DNS NCACHE) 555 S RFC2300 INTERNET OFFICIAL PROTOCOL STANDARDS 556 S RFC2298 An Extensible Message Format for Message Disposition 557 Notifications 558 S RFC2280 Routing Policy Specification Language (RPSL) 559 S RFC2249 Mail Monitoring MIB 560 S RFC2247 Using Domains in LDAP/X.500 Distinguished Names 561 I RFC2230 Key Exchange Delegation Record for the DNS 562 B RFC2219 Use of DNS Aliases for Network Services 563 S RFC2200 INTERNET OFFICIAL PROTOCOL STANDARDS 564 I RFC2187 "Application of Internet Cache Protocol (ICP), version 2" 565 B RFC2182 Selection and Operation of Secondary DNS Servers 566 S RFC2181 Clarifications to the DNS Specification 567 E RFC2168 Resolution of Uniform Resource Identifiers using the Domain 568 Name System 569 I RFC2167 Referral Whois (RWhois) Protocol V1.5 570 S RFC2163 Using the Internet DNS to Distribute MIXER Conformant Global 571 Address Mapping (MCGAM) 572 S RFC2156 MIXER (Mime Internet X.400 Enhanced Relay): Mapping between 573 X.400 and RFC 822/MIME 574 I RFC2151 A Primer On Internet and TCP/IP Tools and Utilities 575 I RFC2146 U.S. Government Internet Domain Names 576 S RFC2142 MAILBOX NAMES FOR "COMMON SERVICES, ROLES AND FUNCTIONS" 577 S RFC2137 Secure Domain Name System Dynamic Update 578 S RFC2136 Dynamic Updates in the Domain Name System (DNS UPDATE) 579 I RFC2133 Basic Socket Interface Extensions for IPv6 580 S RFC2131 Dynamic Host Configuration Protocol 581 I RFC2130 The Report of the IAB Character Set Workshop 582 I RFC2101 IPv4 Address Behaviour Today 583 S RFC2078 "Generic Security Service Application Program Interface, 584 Version 2" 585 S RFC2074 Remote Network Monitoring MIB Protocol Identifiers 586 I RFC2072 Router Renumbering Guide 587 S RFC2068 Hypertext Transfer Protocol -- HTTP/1.1 588 S RFC2065 Domain Name System Security Extensions 589 E RFC2052 A DNS RR for specifying the location of services (DNS SRV) 590 S RFC2034 SMTP Service Extension for Returning Enhanced Error Codes 591 I RFC2010 Operational Criteria for Root Name Servers 592 E RFC2009 GPS-Based Addressing and Routing 593 S RFC2000 INTERNET OFFICIAL PROTOCOL STANDARDS 594 S RFC1996 A Mechanism for Prompt Notification of Zone Changes (DNS 595 NOTIFY) 596 S RFC1995 Incremental Zone Transfer in DNS 597 S RFC1985 SMTP Service Extension for Remote Message Queue Starting 598 I RFC1983 Internet Users' Glossary 599 S RFC1982 Serial Number Arithmetic 600 S RFC1964 The Kerberos Version 5 GSS-API Mechanism 601 I RFC1958 Architectural Principles of the Internet 602 I RFC1955 New Scheme for Internet Routing and Addressing (ENCAPS) for 603 IPNG 604 S RFC1933 Transition Mechanisms for IPv6 Hosts and Routers 605 S RFC1920 INTERNET OFFICIAL PROTOCOL STANDARDS 606 I RFC1919 Classical versus Transparent IP Proxies 607 I RFC1912 Common DNS Operational and Configuration Errors 608 I RFC1900 Renumbering Needs Work 609 S RFC1891 SMTP Service Extension for Delivery Status Notifications 610 I RFC1887 An Architecture for IPv6 Unicast Address Allocation 611 S RFC1886 DNS Extensions to support IP version 6 612 S RFC1880 INTERNET OFFICIAL PROTOCOL STANDARDS 613 I RFC1877 PPP Internet Protocol Control Protocol Extensions for Name 614 Server Addresses 615 E RFC1876 A Means for Expressing Location Information in the Domain Name 616 System 617 E RFC1845 SMTP Service Extension for Checkpoint/Restart 618 I RFC1816 U.S. Government Internet Domain Names 619 S RFC1800 INTERNET OFFICIAL PROTOCOL STANDARDS 620 I RFC1794 DNS Support for Load Balancing 621 E RFC1788 ICMP Domain Name Messages 622 S RFC1780 INTERNET OFFICIAL PROTOCOL STANDARDS 623 I RFC1739 A Primer On Internet and TCP/IP Tools 624 S RFC1720 INTERNET OFFICIAL PROTOCOL STANDARDS 625 I RFC1713 Tools for DNS debugging 626 E RFC1712 DNS Encoding of Geographical Location 627 I RFC1711 Classifications in E-mail Routing 628 I RFC1709 K-12 Internetworking Guidelines 629 I RFC1707 CATNIP: Common Architecture for the Internet 630 I RFC1706 DNS NSAP Resource Records 631 I RFC1705 Six Virtual Inches to the Left: The Problem with IPng 632 I RFC1703 Principles of Operation for the TPC.INT Subdomain: Radio 633 Paging -- Technical Procedures 634 I RFC1671 IPng White Paper on Transition and Other Considerations 635 E RFC1664 Using the Internet DNS to Distribute 636 RFC1327 Mail Address Mapping Tables 637 E RFC1637 DNS NSAP Resource Records 638 I RFC1636 Report of IAB Workshop on Security in the Internet 639 Architecture "February 8-10, 1994" 640 I RFC1630 Universal Resource Identifiers in WWW 641 I RFC1621 Pip Near-term Architecture 642 I RFC1616 X.400(1988) for the Academic and Research Community in Europe 643 S RFC1612 DNS Resolver MIB Extensions 644 S RFC1611 DNS Server MIB Extensions 645 S RFC1610 INTERNET OFFICIAL PROTOCOL STANDARDS 646 E RFC1608 Representing IP Information in the X.500 Directory 647 S RFC1600 INTERNET OFFICIAL PROTOCOL STANDARDS 648 I RFC1597 Address Allocation for Private Internets 649 I RFC1594 FYI on Questions and Answers "Answers to Commonly asked ""New 650 Internet User"" Questions" 651 I RFC1591 Domain Name System Structure and Delegation 652 I RFC1588 WHITE PAGES MEETING REPORT 653 I RFC1569 Principles of Operation for the TPC.INT Subdomain: Radio 654 Paging -- Technical Procedures 655 I RFC1546 Host Anycasting Service 656 S RFC1540 INTERNET OFFICIAL PROTOCOL STANDARDS 657 I RFC1537 Common DNS Data File Configuration Errors 658 I RFC1536 Common DNS Implementation Errors and Suggested Fixes 659 I RFC1535 A Security Problem and Proposed Correction With Widely 660 Deployed DNS Software 661 I RFC1530 Principles of Operation for the TPC.INT Subdomain: General 662 Principles and Policy 663 E RFC1528 Principles of Operation for the TPC.INT Subdomain: Remote 664 Printing -- Technical Procedures 665 S RFC1519 Classless Inter-Domain Routing (CIDR): an Address Assignment 666 and Aggregation Strategy 668 S RFC1500 INTERNET OFFICIAL PROTOCOL STANDARDS 669 - RFC1486 An Experiment in Remote Printing 670 - RFC1480 The US Domain 671 - RFC1470 FYI on a Network Management Tool Catalog: Tools for Monitoring 672 and Debugging TCP/IP Internets and Interconnected Devices 673 - RFC1464 Using the Domain Name System To Store Arbitrary String 674 Attributes 675 - RFC1459 Internet Relay Chat Protocol 676 - RFC1454 Comparison of Proposals for Next Version of IP 677 - RFC1430 A Strategic Plan for Deploying an Internet X.500 Directory 678 Service 679 - RFC1415 FTP-FTAM Gateway Specification 680 - RFC1410 IAB OFFICIAL PROTOCOL STANDARDS 681 - RFC1401 Correspondence between the IAB and DISA on the use of DNS 682 throughout the Internet 683 - RFC1395 BOOTP Vendor Information Extensions 684 - RFC1392 Internet Users' Glossary 685 - RFC1386 The US Domain 686 - RFC1385 EIP: The Extended Internet Protocol A Framework for 687 Maintaining Backward Compatibility 688 - RFC1383 An Experiment in DNS Based IP Routing 689 - RFC1360 IAB OFFICIAL PROTOCOL STANDARDS 690 - RFC1348 DNS NSAP RRs 691 - RFC1347 "TCP and UDP with Bigger Addresses (TUBA)," A Simple Proposal 692 for Internet Addressing and Routing 693 - RFC1335 A Two-Tier Address Structure for the Internet: A Solution to 694 the Problem of Address Space Exhaustion 695 - RFC1325 FYI on Questions and Answers "Answers to Commonly asked ""New 696 Internet User"" Questions" 697 - RFC1309 Technical Overview of Directory Services Using the X.500 698 Protocol 699 - RFC1308 Executive Introduction to Directory Services Using the X.500 700 Protocol 701 - RFC1291 Mid-Level Networks Potential Technical Services 702 - RFC1280 IAB OFFICIAL PROTOCOL STANDARDS 703 - RFC1279 X.500 and Domains 704 - RFC1274 The COSINE and Internet X.500 Schema 705 - RFC1250 IAB OFFICIAL PROTOCOL STANDARDS 706 - RFC1207 FYI on Questions and Answers "Answers to Commonly asked 707 ""Experienced Internet User"" Questions" 708 - RFC1206 FYI on Questions and Answers "Answers to Commonly asked ""New 709 Internet User"" Questions" 710 - RFC1200 IAB OFFICIAL PROTOCOL STANDARDS 711 - RFC1183 New DNS RR Definitions 712 - RFC1177 FYI on Questions and Answers "Answers to Commonly asked ""New 713 Internet User"" Questions" 714 - RFC1175 FYI on Where to Start - A Bibliography of Internetworking 715 Information 716 - RFC1174 IAB Recommended Policy on Distributing Internet Identifier 717 Assignment And "IAB Recommended Policy Change to Internet 718 ""Connected"" Status" 719 - RFC1168 INTERMAIL AND COMMERCIAL MAIL RELAY SERVICES 720 - RFC1147 FYI on a Network Management Tool Catalog: Tools for Monitoring 721 and Debugging TCP/IP Internets and Interconnected Devices 723 - RFC1123 Requirements for Internet Hosts -- Application and Support 724 - RFC1101 DNS Encoding of Network Names and Other Types 725 - RFC1100 IAB OFFICIAL PROTOCOL STANDARDS 726 - RFC1085 ISO Presentation Services on top of TCP/IP-based internets 727 - RFC1083 IAB OFFICIAL PROTOCOL STANDARDS 728 - RFC1035 DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION 729 - RFC1034 DOMAIN NAMES - CONCEPTS AND FACILITIES 730 - RFC0830 A Distributed System for Internet Name Service 732 S - Standards Track I - Informational 733 E - Experimental B - Best Current Practice 735 All idn protocol proposal documents must fully detail the expected 736 effects of leaking of the specified encoding to protocols other than the 737 DNS resolution protocol. 739 4. Security Considerations 741 Any solution that meets the requirements in this document must not 742 be less secure than the current DNS. Specifically, the mapping of 743 internationalized host names to and from IP addresses must have the 744 same characteristics as the mapping of today's host names. 746 Specifying requirements for internationalized domain names does not 747 itself raise any new security issues. However, any change to the DNS may 748 affect the security of any protocol that relies on the DNS or on 749 DNS names. A thorough evaluation of those protocols for security 750 concerns will be needed when they are developed. In particular, IDNs 751 must be compatible with DNSSEC and, if multiple charsets or 752 representation forms are permitted, the implications of this name-spoof 753 must be throughly understood. 755 5. References 757 [CHARREQ] "Requirements for string identity matching and String 758 Indexing", http://www.w3.org/TR/WD-charreq, July 1998, 759 World Wide Web Consortium. 761 [DNSEXT] "IETF DNS Extensions Working Group", 762 namedroppers@internic.net, Olafur Gudmundson, Randy Bush. 764 [RFC1034] "Domain Names - Concepts and Facilities", rfc1034.txt, 765 November 1987, P. Mockapetris. 767 [RFC1035] "Domain Names - Implementation and Specification", 768 rfc1035.txt, November 1987, P. Mockapetris. 770 [RFC1123] "Requirements for Internet Hosts -- Application and 771 Support", rfc1123.txt, October 1989, R. Braden. 773 [RFC1766] Tags for the Identification of Languages, rfc1766.txt, 774 March 1995, H. Alvestrand. 776 [RFC1996] "A Mechanism for Prompt Notification of Zone Changes 777 (DNS NOTIFY)", rfc1996.txt, August 1996, P. Vixie. 779 [RFC2119] "Key words for use in RFCs to Indicate Requirement 780 Levels", rfc2119.txt, March 1997, S. Bradner. 782 [RFC2181] "Clarifications to the DNS Specification", rfc2181.txt, 783 July 1997, R. Elz, R. Bush. 785 [RFC2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646", 786 RFC 2279, January 1998. 788 [RFC2535] "Domain Name System Security Extensions", rfc2535.txt, 789 March 1999, D. Eastlake. 791 [RFC2553] "Basic Socket Interface Extensions for IPv6", rfc2553.txt, 792 March 1999, R. Gilligan and al. 794 [UNIROOT] "IAB Technical Comment on the Unique DNS Root", 795 draft-iab-unique-dns-root-00.txt, iab@iab.org 797 [IABIDN] "A Tangled Web:issues of I18N domain names, and the 798 other Internet protocols", rfc2825.txt 799 iab@iab.org 801 [UNICODE] The Unicode Consortium, "The Unicode Standard -- Version 802 3.0", ISBN 0-201-61633-5. Described at 803 http://www.unicode.org/unicode/standard/versions/ 804 Unicode3.0.html 806 [US-ASCII] Coded Character Set -- 7-bit American Standard Code for 807 Information Interchange, ANSI X3.4-1986. 809 [UTR15] "Unicode Normalization Forms", Unicode Technical Report 810 #15, http://www.unicode.org/unicode/reports/tr15/, 811 Nov 1999, M. Davis & M. Duerst, Unicode Consortium. 813 [UTR21] "Case Mappings", Unicode Technical Report #21, 814 http://www.unicode.org/unicode/reports/tr21/, Dec 1999, 815 M. Davis, Unicode Consortium. 817 6. Editors' Contact 819 Zita Wenzel 820 [ ... ] 822 James Seng 823 8 Temesek Boulevand 824 #24-02 Suntec Tower 3 825 Singapore 038988 826 Tel: +65 248-6208 827 Fax: +65 248-6198 828 Email: jseng@pobox.org.sg 829 7. Acknowledgements 831 The editor gratefully acknowledges the contributions of: 833 Harald Tveit Alvestrand 834 Martin Duerst 835 Patrik Faltstrom 836 Andrew Draper 837 Bill Manning 838 Paul Hoffman 839 James Seng 840 Randy Bush 841 Alan Barret 842 Olafur Gudmundsson 843 Karlsson Kent 844 Dan Oscarsson 845 J. William Semich 846 RJ Atkinson 847 Simon Josefsson 848 Ned Freed 849 Dongman Lee 850 Mark Andrews 851 John Klensin 852 Tan Juay Kwang