Internet DRAFT - draft-arrouye-idn-ie5-resolution
draft-arrouye-idn-ie5-resolution
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]
