idnits 2.17.1 draft-iab-i18n-dns-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- == 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 242 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** 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. ** There are 15 instances of lines with control characters in the document. 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) No issues found here. Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Leslie L. Daigle 2 Expires October 12, 2000. Editor 4 A Tangled Web: issues of I18N, domain names, and the 5 other Internet protocols 7 draft-iab-i18n-dns-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 0.0 Abstract 33 The goals of the work to "internationalize" Internet protocols 34 include providing all users of the Internet with the capability of 35 using their own language and its standard character set to express 36 themselves, write names, and to navigate the network. This impacts 37 the domain names visible in e-mail addresses and so many of today's 38 URLs used to locate information on the World Wide Web, etc. However, 39 domain names are used by Internet protocols that are used across 40 national boundaries. These services must interoperate worldwide, or 41 we risk isolating components of the network from each other along 42 locale boundaries. This type of isolation could impede not only 43 communications among people, but opportunities of the areas involved 44 to participate effectively in e-commerce, distance learning, and 45 other activities at an international scale, thereby retarding 46 economic development. 48 There are several proposals for internationalizing domain names, 49 however it it is still to be determined whether any of them 50 will ensure this interoperability and global reach while addressing 51 visible-name representation. Some of them obviously do not. This 52 document does not attempt to review any specific proposals, as that 53 is the work of the Internationalized Domain Name (IDN) Working Group 54 of the IETF, which is tasked with evaluating them in consideration 55 of the continued global network interoperation that is the deserved 56 expectation of all Internet users. 58 This document elaborates the scope of the problem outside of 59 the domain name system (DNS). 61 1.0 A Definition of Success 63 The Internationalized Domain Names (IDN) Working Group 64 is one component of the IETF's continuing comprehensive effort to 65 internationalize language representation facilities in the protocols 66 that support the global functioning of the Internet. 68 In keeping with the principles of rough consensus, running code, 69 architectural integrity, and in the interest of ensuring the global 70 stability of the Internet, the IAB emphasizes that all solutions 71 proposed to the (IDN) Working Group will have to be evaluated not 72 only on their individual technical features, but also in terms of 73 impact on existing standards and operations of the Internet and the 74 total effect for end-users: solutions must not cause users to 75 become more isolated from their global neighbors even if they appear 76 to solve a local problem. In some cases, existing protocols have 77 limitations on allowable characters, and in other cases 78 implementations of protocols used in the core of the Internet 79 (beyond individual organizations) have in practice not implemented 80 all the requisite options of the standards. 82 2.0 Technical Challenges within DNS 84 In many technical respects, the IDN work is not different from any 85 other effort to enable multiple character set representations in 86 textual elements that were traditionally restricted to English 87 language characters. 89 One aspect of the challenge is to decide how to represent the names 90 users want in the DNS in a way that is clear, technically feasible, 91 and ensures that a name always means the same thing. Several 92 proposals have been suggested to address these issues. 94 These issues are being outlined in more detail in the IDN WG's 95 evolving draft requirements document; further discussion is deferred 96 to the WG and its documents. 98 2.0 Integrating with Current Realities 100 Nevertheless, issues faced by the IDN working group are complex and 101 intricately intertwined with other operational components of the 102 Internet. A key challenge in evaluating any proposed solution is the 103 analysis of the impact on existing critical operational standards 104 which use DNS names. Standards-changes can be effected, but the 105 best path forward is one that takes into account current realities 106 and (re)deployment latencies. In the Internet's global context, it is 107 not enough to update a few isolated systems, or even most of the 108 systems in a country or region. Deployment must be nearly universal 109 in order to avoid the creation of "islands" of interoperation that 110 provide users with less access to and connection from the rest 111 of the world. 113 These are not esoteric or ephemeral concerns. Some specific issues 114 have already been identified as part of the IDN WG's efforts. 116 2.1 Domain Names and E-mail 118 As indicated in the IDN WG's draft requirements document, the 119 issue goes beyond standardization of DNS usage. Electronic mail has 120 long been one of the most-used and most important applications of 121 the Internet. Internet e-mail is also used as the bridge that 122 permits the users of a variety of local and proprietary mail systems 123 to communicate. The standard protocols that define its use (e.g., 124 SMTP (STD10), RFC822, and MIME (RFC2045)) do not permit the full 125 range of characters allowed in the DNS specification. Certain 126 characters are not allowed in e-mail address domain portions of 127 these specifications. Some mailers, built to adhere to these 128 specifications, are known to fail when on mail having non-ASCII 129 domain names in its address -- by discarding, misrouting or damaging 130 the mail. Thus, it's not possible to simply switch to 131 internationalized domain names and expect global e-mail to continue 132 to work until most of the servers in the world are upgraded. 134 2.2 Domain Names and Routing 136 At a lower level, the Routing Policy Specification Language (RPLS) 137 (RFC2622) makes use of "named objects" -- and inherits object 138 naming restrictions from older standards (RFC822 for the same e-mail 139 address restrictions, RFC1034 for hostnames). This means that until 140 routing registries and their protocols are updated, it is not 141 possible to enter or retrieve network descriptions utilizing 142 internationalized domain names. 144 2.3 Domain Names and Network Management 146 Also, the Simple Network Management Protocol (SNMP) uses the textual 147 representation defined in RFC2579. While that specification does 148 allow for UTF-8-based domain names, an informal survey of deployed 149 implementations of software libraries being used to build 150 SNMP-compliant software uncovered the fact that few (if any) 151 implement it. This may cause inability to enter or display correct 152 data in network management tools, if such names are internationalized 153 domain names. 155 2.4 Domain names and security 157 In the Transport Layer Security protocol (TLS), it is common usage 158 that a server displays a certificate containing a domain name 159 purporting to be the domain name of the server, which the client can 160 then match with the server name he thought he used to reach the 161 service. 163 Unless comparision of domain names is properly defined, the 164 client may either fail to match the domain name of a legitimate 165 server, or match incorrectly the domain name of a server 166 performing a man-in-the-middle attack. Either failure could enable 167 attacks on systems that are now impossible or at least far more 168 difficult. 170 3.0 Conclusion 172 It is therefore clear that, although there are many possible ways to 173 assign internationalized names that are compatible with today's DNS 174 (or a version that is easily-deployable in the near future), not all 175 of them are compatible with the full range of necessary networking 176 tools. When designing a solution for internationalization of domain 177 names, the effects on the current Internet must be carefully 178 evaluated. Some types of solutions proposed would, if put into 179 effect immediately, cause Internet communications to fail in ways 180 that would be hard to detect by and pose problems for those who 181 deploy the new services, but also for those who do not; this would 182 have the effect of cutting those who deploy them off from effective 183 use of the Internet. 185 The IDN WG has been identified as the appropriate forum for 186 identifying and discussing solutions for such potential 187 interoperability issues. 189 Experience with deployment of other protocols has indicated that it 190 will take years before a new protocol or enhancement is used all over 191 the Internet. So far, the IDN WG has benefitted from proposed 192 solutions from all quarters, including organizations hoping to 193 provide services that address visible-name representation and 194 registration -- continuing this process with the aim of getting a 195 single, scalable and deployable solution to this problem is the only 196 way to ensure the continued global interoperation that is the 197 deserved expectation of all Internet users. 199 4.0 References 201 STD10 Postel, J.B. "Simple Mail Transfer Protocol," STD10, 202 1982. 204 RFC 822 Crocker, D., "Standard for the Format of ARPA 205 Internet Text Messages", RFC822, 1982. 207 RFC1034 Mockapetris, P., "Domain Names - Concepts and Facilities", 208 RFC1034, 1987. 210 RFC2045 Freed, N., and N. Borenstein, "Multipurpose Internet Mail 211 Extensions (MIME) Part One: Format of Internet Message 212 Bodies", RFC2045, 1996. 214 RFC2579 McCloghrie, K., D. Perkins, J. Schoenwaelder, J. Case, and 215 M. Rose, "Textual Conventions for SMIv2", RF2579, 1999. 217 RFC2622 Alaettinoglu, C., C. Villamizar, E. Gerich, D. Kessens, 218 D. Meyer, T. Bates, D. Karrenberg, and M. Terpstra, 219 "Routing Policy Specification Language (RPSL)", RFC2622, 220 1999. 222 5.0 Editor Contact Information 224 Leslie L. Daigle 225 leslie@rattlenote.com