idnits 2.17.1 draft-ietf-idn-idna-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 273 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) == Missing Reference: 'STD 13' is mentioned on line 197, but not defined == Unused Reference: 'RFC2279' is defined on line 243, but no explicit reference was found in the text -- 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 (~~), 5 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-idna-00.txt IMC & VPNC 3 September 12, 2000 Patrik Faltstrom 4 Expires in six months Cisco 6 Internationalizing Host Names In Applications (IDNA) 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other groups 15 may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 The current DNS infrastructure does not provide a way to use 31 internationalized host names (IDN). This document describes a mechanism 32 that requires no changes to any DNS server or resolver that will allow 33 internationalized host names to be used by end users with changes only 34 to applications. It allows flexibility for user input and display, and 35 assures that host names that have non-ASCII characters are not sent to 36 DNS servers or resolvers. 38 1. Introduction 40 In the discussion of IDN solutions, a great deal of discussion has 41 focused on transition issues and how IDN will work in a world where not 42 all of the components have been updated. Earlier proposed solutions 43 require that user applications, resolvers, and DNS servers to be updated 44 in order for a user to use an internationalized host name. Instead of 45 this requirement for widespread updating of all components, the current 46 proposal is that only user applications be updated; no changes are 47 needed to the DNS protocol or any DNS servers or the resolvers on user's 48 computers. 50 1.1 Design philosophy 52 To date, the proposals for IDN protocols have required that DNS servers 53 be updated to handle internationalized host names. Because of this, the 54 person who wanted to use an internationalized host name had to be sure 55 that their request went to a DNS server that was updated for IDN. 56 Further, that server could only send queries to other servers that had 57 been updated for IDN because the queries contain new protocol elements 58 to differentiate IDN name parts from current host parts. In addition, 59 these proposals require that resolvers must be updated to use the new 60 protocols, and in most cases the applications would need to be updated 61 as well. 63 Updating all (or even a significant percentage) of the DNS servers in 64 the world will be difficult, to say the least. Because of this, we have 65 designed a protocol that requires no updating of any name servers. IDNA 66 still requires the updating of applications, but once a 67 user has updated these, she or he could immediately start using 68 internationalized host names. The cost of implementing IDN would thus be 69 much lower, and the speed of implementation will be much higher. 71 1.2 Terminology 73 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and 74 "MAY" in this document are to be interpreted as described in RFC 2119 75 [RFC2119]. 77 1.3 IDN summary 79 Using the terminology in [IDNCOMP], this protocol specifies an IDN 80 architecture of arch-3 (just send ACE). The format is ace-1.2 (RACE), 81 and the method for distinguishing ACE name parts from current name parts 82 is ace-2.1.1 (add hopefully-unique legal tag). Because there is no 83 changes needed to the DNS, the transition strategy is trans-1 (always do 84 current plus new architecture). 86 2. Structural Overview 88 In IDNA, users' applications are updated to perform the processing 89 needed to input internationalized host names from users, display 90 internationalized host names that are returned from the DNS to users, 91 and process the inputs and outputs from the DNS. 93 2.1 Interfaces between DNS components in IDNA 95 The interfaces in IDNA can be represented pictorially as: 97 +------+ 98 | User | 99 +------+ 100 ^ 101 | Input and display: local interface methods 102 | (pen, keyboard, glowing phosphorus, ...) 103 +--------------- v -------------------------------+ 104 | +-------------+ | 105 | | Application | | End system 106 | +-------------+ 107 | ^ 108 | | API call and return: nameprepped RACE 109 | v 110 | +----------+ 111 | | Resolver | 112 | +----------+ | 113 +----------------^--------------------------------+ 114 | DNS query and response: nameprepped RACE 115 v 116 +-------------+ 117 | DNS servers | 118 +-------------+ 120 2.1.1 Users and applications 122 Applications can accept host names using any character set or sets 123 desired by the application developer, and can display host names in any 124 charset. That is, this protocol does not affect the interface between 125 users and applications. 127 An IDNA-aware application can accept and display internationalized host 128 names in two formats: the internationalized character set(s) supported 129 by the application, and in RACE [RACE] ASCII-compatible encoding. 130 Applications MAY allow RACE input and output, but are not encouraged to 131 do so except as an interface for advanced users, possibly for debugging. 132 RACE encoding is opaque and ugly, and should thus only be exposed to 133 users who absolutely need it. The optional use, especially during a 134 transition period, of RACE encodings in the user interface is described 135 in section 3. Since RACE can be rendered either as the encoded ASCII 136 glyphs or the proper decoded character glyphs, the rendering engine for 137 an application SHOULD have an option for the user to select the 138 preferred display; if it does, rendering the RACE SHOULD NOT be the 139 default. 141 2.1.2 Applications and resolvers 143 Applications communicate with resolver libraries through a programming 144 interface (API). Typically, the IETF does not standardize APIs, although 145 it has for IPv6. This protocol does not specify a specific API, but 146 instead specifies only the input and output formats of the host names to 147 the resolver library. 149 Before converting the name parts into RACE, the application MUST prepare 150 each name part as specified in [NAMEPREP]. The application MUST use RACE 151 ASCII-compatible encoding for the name parts that are sent to the 152 resolver, and will always get name parts encoded in RACE from the 153 resolver. 155 IDNA-aware applications MUST be able to work with both 156 non-internationalized host name parts (those that conform to RFC 1035 157 [STD13]) and internationalized host name parts. An IDNA-aware 158 application that is resolving a non-internationalized host name parts 159 MUST NOT do any preparation or conversion to RACE on any 160 non-internationalized name part. 162 2.1.3 Resolvers and DNS servers 164 An operating system might have a set of libraries for converting host 165 names to nameprepped RACE. The input to such a library might be in one 166 or more charsets that are used in applications (UTF-8 and UTF-16 are 167 likely candidates for almost any operating system, and script-specific 168 charsets are likely for localized operating systems). The output would 169 be either the unchanged name part (if the input already conforms to [STD 170 13]), or the nameprepped, RACE-encoded name part. Such a library would 171 help keep applications smaller. 173 DNS servers MUST use the RACE format for internationalized host name 174 parts. 176 If a signalling system which makes negotiation possible between old and 177 new DNS clients and servers is standardized in the future, the encoding 178 of the query in the DNS protocol itself can be changed from RACE to 179 something else, such as UTF-8. The question whether or not this should 180 be used is, however, a separate problem and is not discussed in this 181 memo. 183 2.1.4 Avoiding exposing users to the raw ACE encoding 185 All applications that might show the user a host name that was received 186 from a gethostbyaddr or other such lookup SHOULD update as soon as 187 possible in order to prevent users from seeing the ACE. However, this is 188 not considered a big problem because so few applications show this type 189 of resolution to users. 191 3. Name Server Considerations 193 It is imperative that there be only one encoding for a particular host 194 name. RACE is an encoding for host name parts that use characters 195 outside those allowed for host names [STD 13]. Thus, a primary master 196 name server MUST NOT contain an RACE-encoded name that decodes to a host 197 name that is allowed in [STD 13]. 199 Name servers MUST NOT have any records with host names that contain 200 internationalized name parts unless those name parts have be prepared 201 according to [NAMEPREP]. If names that are not legal in [NAMEPREP] are 202 passed to an application, it will result in an error being passed to the 203 application with no error being reported to the name server. Further, no 204 application will ever ask for a name that is not legal in [NAMEPREP] 205 because requests always go through [NAMEPREP] before getting to the DNS. 207 The host name data in zone files (as specified by section 5 of RFC 1035) 208 MUST be both nameprepped and RACE encoded. 210 4. Root Server Considerations 212 Because there are no changes to the DNS protocols, adopting this 213 protocol has no effect on the root servers. 215 5. Security Considerations 217 Much of the security of the Internet relies on the DNS. Thus, any change 218 to the characteristics of the DNS can change the security of much of the 219 Internet. 221 Host names are used by users to connect to Internet servers. The 222 security of the Internet would be compromised if a user entering a 223 single internationalized name could be connected to different servers 224 based on different interpretations of the internationalized host name. 226 Because this document normatively refers to [NAMEPREP], it includes the 227 security considerations from that document as well. 229 6. References 231 [IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name 232 Proposals", draft-ietf-idn-compare. 234 [NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of 235 Internationalized Host Names", draft-ietf-idn-nameprep. 237 [RACE] RACE: Row-based ASCII Compatible Encoding for IDN, 238 draft-ietf-idn-race. 240 [RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate 241 Requirement Levels", March 1997, RFC 2119. 243 [RFC2279] Francois Yergeau, "UTF-8, a transformation format of ISO 244 10646", January 1998, RFC 2279. 246 [STD13] Paul Mockapetris, "Domain names - implementation and 247 specification", November 1987, STD 13 (RFC 1035). 249 A. Authors' Addresses 251 Paul Hoffman 252 Internet Mail Consortium and VPN Consortium 253 127 Segre Place 254 Santa Cruz, CA 95060 USA 255 phoffman@imc.org 257 Patrik Faltstrom 258 Cisco Systems 259 170 West Tasman Drive SJ-13/2 260 San Jose, CA 95134 USA 261 paf@cisco.com