ICANNWatch
 
  Inside ICANNWatch  
Submit Story
Home
Lost Password
Preferences
Site Messages
Top 10 Lists
Latest Comments
Search by topic

Our Mission
ICANN for Beginners
About Us
How To Use This Site
ICANNWatch FAQ
Slash Tech Info
Link to Us
Write to Us

  Useful ICANN sites  
  • ICANN itself
  • Bret Fausett's ICANN Blog
  • Internet Governance Project
  • UN Working Group on Internet Governance
  • Karl Auerbach web site
  • Müller-Maguhn home
  • UDRPinfo.com;
  • UDRPlaw.net;
  • CircleID;
  • LatinoamerICANN Project
  • ICB Tollfree News

  •   At Large Membership and Civil Society Participation in ICANN  
  • icannatlarge.com;
  • Noncommercial Users Constituency of ICANN
  • NAIS Project
  • ICANN At Large Study Committee Final Report
  • ICANN (non)Members page
  • ICANN Membership Election site

  • ICANN-Related Reading
    Browse ICANNWatch by Subject

    Ted Byfied
    - ICANN: Defending Our Precious Bodily Fluids
    - Ushering in Banality
    - ICANN! No U CANN't!
    - roving_reporter
    - DNS: A Short History and a Short Future

    David Farber
    - Overcoming ICANN (PFIR statement)

    A. Michael Froomkin
    - When We Say US™, We Mean It!
    - ICANN 2.0: Meet The New Boss
    - Habermas@ discourse.net: Toward a Critical Theory of Cyberspace
    - ICANN and Anti-Trust (with Mark Lemley)
    - Wrong Turn in Cyberspace: Using ICANN to Route Around the APA & the Constitution (html)
    - Form and Substance in Cyberspace
    - ICANN's "Uniform Dispute Resolution Policy"-- Causes and (Partial) Cures

    Milton Mueller
    - Ruling the Root
    - Success by Default: A New Profile of Domain Name Trademark Disputes under ICANN's UDRP
    - Dancing the Quango: ICANN as International Regulatory Regime
    - Goverments and Country Names: ICANN's Transformation into an Intergovernmental Regime
    - Competing DNS Roots: Creative Destruction or Just Plain Destruction?
    - Rough Justice: A Statistical Assessment of the UDRP
    - ICANN and Internet Governance

    David Post
    - Governing Cyberspace, or Where is James Madison When We Need Him?
    - The 'Unsettled Paradox': The Internet, the State, and the Consent of the Governed

    Jonathan Weinberg
    - Sitefinder and Internet Governance
    - ICANN, Internet Stability, and New Top Level Domains
    - Geeks and Greeks
    - ICANN and the Problem of Legitimacy

    Highlights of the ICANNWatch Archive
    (June 1999 - March 2001)


     
    This discussion has been archived. No new comments can be posted.
    XTNS offers new gTLDs (sort of) | Log in/Create an Account | Top | 127 comments | Search Discussion
    Click this button to post a comment to this story
    The options below will change how the comments display
    Threshold:
    Check box to change your default comment view
    The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
    Re: Ask XTNS, not this board
    by Anonymous on Tuesday September 04 2001, @04:45AM (#2186)
    I lack confidence that you can figure out how to follow a link, so here's the whole thing for ya. (In XTNS's case the only key difference is that the RN servers pass the entire string to the XTNS servers, rather than to mltbd.com in the Verisign case). I guess XTNS's success or failure is pretty much whatever you feel Verisign's success or failure to be -- I differ in your estimate as to which this will be, but we each have our right to express our opinion and time will tell who is right:
    ------------------------

    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.

    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

    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.

    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
    u30EAu30A2u30EBu30FCu30E0u30BA.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
    u30EAu30A2u30EBu30FCu30E0u30BA.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 u30EAu30A2u30EBu30FCu30E0u30BA.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.)

    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
    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/
    [ Reply to This | Parent ]
    Re: Ask XTNS, not this board by Anonymous
    Re: Ask XTNS, not this board
    by Anonymous on Tuesday September 04 2001, @05:48AM (#2189)
    And for those who want the link to the paper that discusses the XTNS/RealNames system which Verisign has adopted:
    http://www.i-d-n.net/draft/draft-arrouye-idn-ie5-resolution-00.txt
    [ Reply to This | Parent ]


    Search ICANNWatch.org:


    Privacy Policy: We will not knowingly give out your personal data -- other than identifying your postings in the way you direct by setting your configuration options -- without a court order. All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 by ICANNWatch.Org. This web site was made with Slashcode, a web portal system written in perl. Slashcode is Free Software released under the GNU/GPL license.
    You can syndicate our headlines in .rdf, .rss, or .xml. Domain registration services donated by DomainRegistry.com