INTERNET-DRAFT Y. Arrouye June 27, 2001 RealNames Corp. Expires December 27, 2001 IDN Resolution in Windows Internet Explorer 5.0 and Above draft-arrouye-idn-ie5-resolution-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document describes how internationalized domain names (IDNs) are being resolved in the Windows Internet Explorer (IE) Web browser version 5.0 and above. The resolution that is described in this document is currently available on a limited basis for an existing test bed. This document focuses on the different steps that are taken after a user enters an IDN in the address bar of IE, up to when the relevant Web page is displayed in the user's browser. 1. Introduction Registration of IDNs in the .com, .org, and .net top-level domains has been available as a test bed since November 10, 2000. This test bed now contains nearly one million registered IDNs. The test bed consists of multiple phases. While the first phases only consisted in registration and hosting of an informational Web page by VeriSign, it is today possible for IDNs owners to assign them to one of their hosts, and to control the content that is delivered from these hosts, making IDNs useful for the first time. Arrouye [Page 1] draft-arrouye-idn-ie5-resolution-00.txt 27 June 2001 The greatest hurdle in the deployment of this IDN test bed has been the lack of support from applications. Users had to download a plug- in for their Web browser or their Windows operating system in order to be able to use IDNs. This requirement meant that availability of IDNs was severely limited, as people do not usually download such plug-ins, or are simply not aware of their existence. RealNames (Keyword: RealNames, http://www.realnames.com/) recently added IDN resolution to its resolution services. Thanks to the use of these services by Internet Explorer, IE users of version 5.0 and above on Windows have access to IDNs without the need to use a plug- in or do any special configuration. This document explains how this IDN resolution works. 2. Overview of the VeriSign Test Bed Information about the VeriSign IDN test bed can be found at http://www.verisign-grs.com/idn/ so this section will simply give some basic information about it. IDNs can be subscribed in the .com, .org, and .net top-level domains through accredited registrars. The registrars do perform the Nameprep [NAMEPREP] step, as well as a RACE-encoding [RACE] step, on the names, and submit the resulting encoded string to the VeriSign GRS through RRP [RFC2832]. The subscribed names then go into a test bed, by placing them in a secondary level domain name. This is achieved by replacing the top-level domain TLD by .mltdb.TLD. The RACE-encoded subscription bq--gdvkf26n7tqlu.com is actually accessible only as bq--gdvkf26n7tqlu.mltbd.com. This prevents ACE-encoded strings to be visible in the top-level domain zone files. A later phase of the test bed may remove this restriction. The names in the .mltbd.com, .mltbd.org, and .mltbd.net test bed zones can still be managed by their buyers through delegation of their resolution from VeriSign. This is what is happening currently, in phase 3.2 of the test bed. 3. Name Resolution in Internet Explorer The process of name resolution, or more correctly user input resolution, in IE, is as follows: - The user types some address in the IE address bar. - IE checks whether the address looks like a valid URI [RFC2396] with a scheme. If that is the case, it tries to resolve that URI. - If the address does not look like a valid URI, but like a domain Arrouye [Page 2] draft-arrouye-idn-ie5-resolution-00.txt 27 June 2001 name, IE first does a DNS lookup of the domain name after encoding it in UTF-8. If the lookup is successful, IE assumes that the user wants to do an HTTP [RFC2616] request for the document / on this host, and tries to fetch it. - If the DNS lookup failed, or if the address does not look like a valid URI, IE sends the full user input, in UTF-8, to auto.search.msn.com, a server that implements IE's Autosearch functionality. - Autosearch is faced with two kinds of inputs. Genuine Autosearch queries are handled by MSN, which is the integration point for both search and the RealNames Keywords navigation system. Failed DNS queries are sent directly to the RealNames servers for further handling, as explained in the section "RealNames IDN Resolution Service." 4. RealNames IDN Resolution Service The RealNames IDN resolution service is embedded in the RealNames Keywords routers [RNS], systems dedicated to the task of name resolution for the Internet. One of the available interfaces is HTTP- based, and works by returning HTTP redirects (302) as answers to an HTTP GET queries for name resolution. As a result, the user's HTTP client will get the desired named resource. The RealNames routers map a name to a destination. They were initially built to simply handle Keywords, and have been recently extended to handle different kinds of names. These names are called multilingual identifiers (MLIs) in this document. MLIs are segregated into different categories, or types, and may be resolved differently depending on their type. The initial type of MLI was a Keyword. In this document, we are interested into another type, the IDN. When an MLI is passed to a RealNames router, it first needs to be categorized. IDNs are being recognized by doing a syntax check as well as testing whether they can be encoded successfully for consumption by the existing DNS. IDNs are also being checked against a table of valid TLDs for IDNs, since they are not available everywhere as of this writing. Names that do not belong to the right TLDs are handled as Keywords (the default fall-back identifier category in the RealNames system). Once an MLI has been categorized as an IDN, is encoded by following the steps described in the IDNA [IDNA] Internet-Draft: the Nameprep algorithm is applied to the name, and then it is encoded using an ACE. Arrouye [Page 3] draft-arrouye-idn-ie5-resolution-00.txt 27 June 2001 In order to be able to support different IDN deployment environments, the ACE used for the encoding of the name after Nameprep does depend on the TLD of the IDN. In our example of the VeriSign test bed, it is RACE. For the same reason, any post-processing of the name is also keyed off the TLD. In our example, the post-processing is the insertion of the .mltbd secondary-level domain in the now DNS- friendly name. Once a DNS-friendly name has been produced, the RealNames routers simply redirect to it. The following is a step-by-step illustration of this process. The notation \uNNNN is used to represent the Unicode code point U+NNNN. - A RealNames router is asked to resolve the name \u30EA\u30A2\u30EB\u30FC\u30E0\u30BA.COM This request comes as an HTTP GET request from auto.search.msn.com, as discussed before. - The name is categorized as an IDN. - The Nameprep algorithm is applied to this name, and its output is \u30EA\u30A2\u30EB\u30FC\u30E0\u30BA.com (uppercase letters have been mapped to lowercase ones). - The name is then encoded by applying RACE-encoding to each of its internationalized parts. The result of this encoding is bq--gdvkf26n7tqlu.com which is a DNS-friendly name. - The post-processing for .com names is now applied to this DNS- friendly name. As we have said before, this means that .mltbd is inserted as a secondary-level domain. The name is now bq--gdvkf26n7tqlu.mltbd.com. - Finally, the RealNames router sends an HTTP redirect to http://bq--gdvkf26n7tqlu.mltbd.com as its answer to the name resolution query. At that point, the name resolution is complete, and the user of the Web client that made the original request will get the desired content. Note that in order to enhance user experience, the RealNames routers accept partial URIs (URIs without a scheme) as input and correctly categorize them based on the host in the URI. So for example, the input \u30EA\u30A2\u30EB\u30FC\u30E0\u30BA.COM/foo.html will bring http://bq--gdvkf26n7tqlu.mltbd.com/foo.html as a user would expect. (To see a real page instead of an error, replace foo.html with Virtual.asp?page=JP_Corporate_PressListing in the above example.) Arrouye [Page 4] draft-arrouye-idn-ie5-resolution-00.txt 27 June 2001 5. Other Considerations The technology that is described here is limited to the resolution of IDNs in a Web browsing context. Moreover, it is limited to IDNs being entered by the user in the browser's address line, not as part of a valid URI, whether it be in the browser's address line or in a document manipulated by the browser. The goal of this setup is to enhance the user experience of people that type domain names, and now internationalized ones, as Web addresses, by giving them access to a new world of names they have been requesting. RealNames technology can be used through various protocols, such as HTTP and CNRP [CNRP]. With Microsoft IE 5.0 or above for Windows, its HTTP interface can be leveraged out of the box to offer name resolution services oriented towards user's navigation needs. The current setup, which adds IDN resolution to RealNames Keywords technology, is a good example of how flexible our platform is, and how IDN resolution can be offered today, even if different TLDs require different setups. Note that RealNames IDN resolution technology is not enabled for every single TLD. One of the reason for this is that different TLDs may use different resolution mechanims, or test beds. The other reason is that this is currently run as a commercial service, and activation requires a business agreement between the registry of a given TLD and RealNames Corporation. 6. Conclusion Since internationalized domain names have been available for sale in the .com, .org, and .net top-level domains, the biggest hurdle to their use has been the lack of an application that supports them out of the box. RealNames, through its partnership with Microsoft, offers a solution for the user of Windows Internet Explorer 5.0 or above, that works without any necessary modification to one's environment, removing the biggest barrier to the use of internationalized domain names by these users. 7. References [CNRP] N. Popp, M. Mealling, and M. Moseley, Common Name Resolution Protocol (CNRP), draft-ietf-cnrp-10.txt, June 2001. [IDNA] P. Falstrom and P. Hoffman, Internationalizing Host Names in Applications (IDNA), draft-ietf-idn-idna-02.txt, June 2001. [NAMEPREP] P. Hoffman and M. Blanchet, Preparation of Internationalized Host Names, draft-ietf-idn-nameprep-03.txt, January Arrouye [Page 5] draft-arrouye-idn-ie5-resolution-00.txt 27 June 2001 2001. [RACE] P. Hoffman, RACE: Row-based ASCII Compatible Encoding for IDN, draft-ietf-idn-race-03.txt, November 2000. [RFC2396] T. Berners-Lee, R. Fielding, L. Masinter, Uniform Resource Identifiers (URI): Generic Syntax, RFC 2396, August 1998. [RFC2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee, Hypertext Transfer Protocol - HTTP/1.1, June 1999. [RFC2832] S. Hollenbeck and M. Srivastava, NSI Registry Registrar Protocol (RRP), Version 1.1.0, RFC 2832, May 2000. [RNS] Y. Arrouye, The RealNames System - An International Human- Friendly Web Navigation System, http://www.internetkeywords.org/iuc/realnames-iuc16-paper.htm, Proceedings of the 16th International Unicode Conference, Amsterdam, The Netherlands, March 2000. [UNICODE] The Unicode Consortium, The Unicode Standard - Version 3.0, ISBN 0-201-61633-5, January 2000. (Version 3.1 of the standard is available at http://www.unicode.org/unicode/reports/tr27/ and was published in May 2001.) Author's Address Yves Arrouye RealNames Corporation 150 Shoreline Drive Redwood City, CA 94065 Phone: (650) 486-5503 E-mail: yves@realnames.com Keyword: RealNames Web: http://www.realnames.com/ Arrouye [Page 6]