idnits 2.17.1 draft-ietf-idn-idnra-00.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 335 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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) -- Possible downref: Normative reference to a draft: ref. 'IDNCOMP' -- Possible downref: Normative reference to a draft: ref. 'RACE' ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Paul Hoffman 2 draft-ietf-idn-idnra-00.txt IMC & VPNC 3 August 17, 2000 Patrik Faltstrom 4 Expires in six months Cisco 6 Internationalized Host Names 7 Using Resolvers and Applications (IDNRA) 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "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 The current DNS infrastructure does not provide a way to use 32 internationalized host names (IDN). This document describes a mechanism 33 that requires no changes to any DNS server that will allow 34 internationalized host names to be used by end users with changes only 35 to resolvers and applications. It allows flexibility for user input and 36 display, and assures that host names that have non-ASCII characters are 37 not sent to servers. 39 1. Introduction 41 In the discussion of IDN solutions, a great deal of discussion has 42 focused on transition issues and how IDN will work in a world where not 43 all of the components have been updated. Earlier proposed solutions 44 require that user applications, resolvers, and DNS servers to be updated 45 in order for a user to use an internationalized host name. Instead of 46 this requirement for widespread updating of all components, the current 47 proposal is that only user applications and the resolvers on user's 48 systems be updated; no changes are needed to the DNS protocol or any DNS 49 servers. We also show that it is enough to update only the application, 50 and at the same time an encoded version of the host name can be used 51 even in current existing applications. 53 The proposal is called IDNRA because it only requires changes to 54 resolvers and applications (the "R" and "A" in the name). 56 1.1 Design philosophy 58 To date, the proposals for IDN protocols have required that DNS servers 59 be updated to handle internationalized host names. Because of this, the 60 person who wanted to use an internationalized host name had to be sure 61 that their request went to a DNS server that was updated for IDN. 62 Further, that server could only send queries to other servers that had 63 been updated for IDN because the queries contain new protocol elements 64 to differentiate IDN name parts from current host parts. In addition, 65 these proposals require that resolvers must be updated to use the new 66 protocols, and in most cases the applications would need to be updated 67 as well. 69 Updating all (or even a significant percentage) of the DNS servers in 70 the world will be difficult, to say the least. Because of this, we have 71 designed a protocol that requires no updating of any name servers. IDNRA 72 still requires the updating of applications and resolvers, but once a 73 user has updated these, she or he could immediately start using 74 internationalized host names. The cost of implementing IDN would thus be 75 much lower, and the speed of implementation will be much higher. 77 IDNRA also specifies how to use old applications and/or old resolvers in 78 parallel with updated ones. 80 1.2 Terminology 82 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and 83 "MAY" in this document are to be interpreted as described in RFC 2119 84 [RFC2119]. 86 1.3 IDN summary 88 Using the terminology in [IDNCOMP], this protocol specifies an IDN 89 architecture of arch-3 (just send ACE). The format is ace-1.2 (RACE), 90 and the method for distinguishing ACE name parts from current name parts 91 is ace-2.1.1 (add hopefully-unique legal tag). Because there is no 92 changes needed to the DNS, the transition strategy is trans-1 (always do 93 current plus new architecture). 95 2. Structural Overview 97 In IDNRA, users' applications and resolvers are updated to perform the 98 processing needed to input internationalized host names from users, 99 display internationalized host names that are returned from the DNS to 100 users, and process the inputs and outputs from the DNS. 102 2.1 Interfaces between DNS components in IDNRA 104 The interfaces in IDNRA can be represented pictorially as: 106 +------+ 107 | User | 108 +------+ 109 ^ 110 | Input and display: any charset 111 v 112 +-------------+ 113 | Application | 114 +-------------+ 115 ^ 116 | API call and return: UTF-8 117 v 118 +----------+ 119 | Resolver | 120 +----------+ 121 ^ 122 | DNS query and response: RACE 123 v 124 +-------------+ 125 | DNS servers | 126 +-------------+ 128 2.1.1 Users and applications 130 Applications can accept host names using any character set or sets 131 desired by the application developer, and can display host names in any 132 charset. That is, this protocol does not affect the interface between 133 users and applications. 135 An IDNRA-aware application can accept and display internationalized host 136 names in two formats: the internationalized character set(s) supported 137 by the application, and in RACE [RACE] ASCII-compatible encoding. 138 Applications MAY allow RACE input and output, but are not encouraged to 139 do so except as an interface for advanced users, possibly for debugging. 140 RACE encoding is opaque and ugly, and should thus only be exposed to 141 users who absolutely need it. The optional use, especially during a 142 transition period, of RACE encodings in the user interface is described 143 in section 3. 145 2.1.2 Applications and resolvers 147 Applications communicate with resolver libraries through a programming 148 interface (API). Typically, the IETF does not standardize APIs, although 149 it has for IPv6. This protocol does not specify a specific API, but 150 instead specifies only the input and output formats of the host names to 151 the resolver library. 153 This protocol specifies that host names SHOULD be passed to resolvers 154 using UTF-8 [RFC2279] because there are many libraries for converting 155 between arbitrary charsets and UTF-8. However, because the API is not 156 specified in this document, some resolvers may use different charsets 157 for input and output, and applications must, of course, use the same 158 charset as the resolver library they call. 160 IDNRA-aware applications MUST be able to work with both IDNRA-aware and 161 non-aware resolvers. An IDNRA-aware application that is resolving a 162 non-internationalized host name (one that conforms to RFC 1035[STD13]) 163 MUST use non-aware APIs such as "gethostbyname" and "gethostbyaddr". An 164 IDNRA-aware application that is resolving a internationalized host name 165 (one that does not conform to RFC 1035) MUST use an API that is specific 166 to IDNRA. 168 2.1.3 Resolvers and DNS servers 170 Before converting the name parts into RACE, the resolver MUST prepare 171 each name part as specified in [NAMEPREP]. The resolver MUST use RACE 172 ASCII-compatible encoding for the name parts that are sent in the DNS 173 query, and will always get name parts encoded in RACE from the DNS 174 service. DNS servers MUST use the RACE format for internationalized host 175 name parts. 177 If a signalling system which makes negotiation possible between old and 178 new DNS clients and servers is standardized in the future, the encoding 179 of the query in the DNS protocol itself can be changed from RACE to 180 something else, such as UTF-8. The question whether or not this should 181 be used is, however, a separate problem and is not discussed in this 182 memo. 184 3. Combinations of Resolvers and Applications 186 IDNRA allows non-IDNRA applications to coexist with IDNRA-aware 187 resolvers, and non-IDNRA resolvers to coexist with IDNRA-aware 188 applications. This section describes the interactions between 189 applications and resolvers as users update each separately. 191 In this section, "old" means an application or resolver that has not bee 192 upgraded to be IDNRA-aware, and "new" means an IDNRA-aware application 193 or resolver. The two APIs are also called "old" and "new". "Binary" 194 means any host name that is not compatible with current DNS character 195 restrictions. 197 3.1 Old application, old resolver 199 Because it is an old resolver (and an old application), all host names 200 MUST (and will) be resolved using the old API. A user cannot enter 201 binary names in the application. A user MAY enter a name that uses RACE 202 encoding. Each RACE-encoded name part in such a name MUST already have 203 had all name preparation done on it and be correctly converted to RACE 204 encoding; otherwise, it will not be matched in the DNS. 206 When the resolver receives a RACE name in a response to a old API 207 gethostbyaddr-type query, the resolver will not convert the host name to 208 a binary form, and the application will thus display the name in RACE 209 format. Showing the results of a gethostbyaddr-type queries is rare in 210 typical Internet applications, so the display of RACE names is not 211 likely in typical environments. 213 3.2 Old application, new resolver 215 Because it is an old application, all host names MUST (and will) be 216 resolved using the old API. A user cannot enter binary names in the 217 application. A user MAY enter a name that uses RACE encoding. Each 218 RACE-encoded name part in such a name MUST already have had all name 219 preparation done on it and be correctly converted to RACE encoding; 220 otherwise, it will not be matched in the DNS. Note that, even though the 221 resolver is new, the resolver MUST NOT do further name preparation on 222 RACE-encoded name parts because the call was using the old API, which 223 tells the resolver that the resolver is dealing with an old application. 225 If the resolver receives a RACE name in a response to a old API 226 gethostbyaddr-type query, the resolver MUST NOT convert the host name to 227 a binary form, and the application will thus display the name in RACE 228 format. Showing the results of a gethostbyaddr-type queries is rare in 229 typical Internet applications, so the display of RACE names is not 230 likely in typical environments. 232 3.3 New application, old resolver 234 Because it is an old resolver, all host names MUST (and will) be 235 resolved using the old API. If the user enters a binary host name, the 236 application SHOULD reject the name as illegal. This is due to the fact 237 that, if the application did not reject the name as illegal, the 238 application would have to contain all of the name preparation logic and 239 RACE-encoding logic, but that logic would only be used in the rare case 240 where a user had updated applications but not the resolver. It is likely 241 that applications would not fully implement and rigorously test the name 242 preparation logic, and it is therefore likely that some applications in 243 this scenario would give incorrect information to the user, and would 244 possibly be susceptible to spoofing attacks. If an application is going 245 allow the input of binary names and convert them to their RACE-encoded 246 form for use on the old API, the application MUST do full name 247 preparation exactly as it would have been done in a new resolver. 249 If the application receives a RACE-encoded name part in a response to a 250 old API gethostbyaddr-type query, the application SHOULD convert the 251 host name to a binary form for display. However, the application MAY 252 have an interface that allows the display of RACE names that are 253 returned by gethostbyaddr-type queries, but the default setting of such 254 an interface SHOULD be to show the binary form, not the RACE form. 256 3.4 New application, new resolver 258 All host names MUST be resolved using the new API. A user MAY enter a 259 name that uses RACE encoding. Each RACE-encoded name part in such a name 260 MUST already have had all name preparation done on it and be correctly 261 converted to RACE encoding; otherwise, it will not be matched in the 262 DNS. 264 When the resolver receives a RACE name in a response to a 265 gethostbyaddr-type query, if the query was to the old API, the resolver 266 MUST NOT convert the host name and MUST pass the RACE-formatted name to 267 the application. If the query was to the new API, the resolver MUST 268 convert the host name part to the binary form. The application MAY have 269 an interface that allows the user to decide whether to use the old or 270 new API, and therefore to show the results in RACE or binary format, but 271 the default setting of such an interface SHOULD be to use the new API. 273 4. Root Server Considerations 275 Because there are no changes to the DNS protocols, adopting this 276 protocol has no effect on the root servers. 278 5. Security Considerations 280 Much of the security of the Internet relies on the DNS. Thus, any change 281 to the characteristics of the DNS can change the security of much of the 282 Internet. 284 Host names are used by users to connect to Internet servers. The 285 security of the Internet would be compromised if a user entering a 286 single internationalized name could be connected to different servers 287 based on different interpretations of the internationalized host name. 289 Because this document normatively refers to [NAMEPREP], it includes the 290 security considerations from that document as well. 292 6. References 294 [IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name 295 Proposals", draft-ietf-idn-compare. 297 [NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of 298 Internationalized Host Names", draft-ietf-idn-nameprep. 300 [RACE] RACE: Row-based ASCII Compatible Encoding for IDN, 301 draft-ietf-idn-race. 303 [RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate 304 Requirement Levels", March 1997, RFC 2119. 306 [RFC2279] Francois Yergeau, "UTF-8, a transformation format of ISO 307 10646", January 1998, RFC 2279. 309 [STD13] Paul Mockapetris, "Domain names - implementation and 310 specification", November 1987, STD 13 (RFC 1035). 312 A. Authors' Addresses 314 Paul Hoffman 315 Internet Mail Consortium and VPN Consortium 316 127 Segre Place 317 Santa Cruz, CA 95060 USA 318 phoffman@imc.org 320 Patrik Faltstrom 321 Cisco Systems 322 170 W Tasman Drive SJ-13/2 323 San Jose, CA 9 5134 USA 324 paf@cisco.com