Internet DRAFT - draft-xhshi-dns-search


Integrating layered DNS search services within user agents. October 2002

Shi Xiaohong             Expires - April 2003                 [Page 1]

Internet Draft                                             Xiaohong SHI
                                                              Karen LIU
Document: draft-xhshi-dns-search-00.txt                     Inter China
                                                       Network Software
                                                               Co., Ltd
Expires: April 2003                                        October 2002

   Integrating layered DNS search services within user agents

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [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-

   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
   The list of Internet-Draft Shadow Directories can be accessed at


   This document presents a user perspective to the notion of DNS search
   layers as defined by John Klensin's DNS search model [DNS_SEARCH]. In
   particular, the authors look at the integration of name lookup
   results from layer 2, 3 and 4 services to discuss the presentation of
   these results across popular desktop applications such as Web
   browsing and email clients. The goal of this document is not to
   propose a standard UI to the DNS search problem (clearly something
   out of the scope of any IETF work). Instead, the document seeks to
   demonstrate that layered search services can be easily integrated
   within traditional desktop applications; hence that deployment of DNS
   search services is realistic and could rapidly be achieved. It is
   important to understand that the proposed form of integration and
   choice of user interfaces are not fundamental. In fact, the authors
   expect many competing systems to pursue different alternative
   solutions. However, in order to achieve critical deployment mass, it
   is crucial to demonstrate that the architectural model proposed by
   DNS search lends itself to simple user interfaces where different and
   possibly competing services can complete each other to provide a more
   precise and complete navigation experience for the end-user. This
   draft attempts to fulfill that goal by looking at possible solutions
   for popular navigation use cases.

Table of Contents

   1. Web browser integration
   2. Email integration
   3. Generalization: the desktop navigation companion
   4. Security Considerations
   5. Conclusion
   6. References
   7. Acknowledgement
   8. Author's Addresses


   One of the fundamental goals of the DNS-Search architecture is to
   enable the proliferation of layer 2 and layer 3 services. Layer 2
   services are localized name repositories of names and metadata
   capable of better handling name ambiguity and localization
   constraints than the DNS. In a layer two service, the metadata is
   restricted to the name and a small number of standardized facets.
   Layer 3 services, on the other hand, are more vertically focused
   databases (e.g. an e-commerce site on books, a industry-focused
   portal, a medical journal article searchable database). They can
   offer more localized services (local yellow pages, classified, local
   news archive) or more specialized content (library search, patent
   file search, legal case search, chemicals index etc). In fact, layer
   3 services are capable of hosting a broader range of metadata, with
   extended data schema typically adapted to their targeted problem

   An important goal of this draft is to propose an integration scenario
   that enables the insertion of layer 2 databases and lookup services
   into traditional applications with minimal disruption. This is
   especially important as the quality and the breadth of the layer 2
   data incrementally develop but is initially insufficient to provide a
   complete navigation experience.

1.   Web browser integration

   Today, Internet navigation is mainly realized through the DNS (layer
   1 services). On the Web, textual search engines such as Google,
   Altavista or MSN Search (layer 4 services) have also come to play an
   important role for accessing Web pages. Web navigation presents a
   particularly interesting case because modern desktop Web browsers
   have already integrated these two fundamentally disparate navigation
   mechanisms into the single interface of the URL address bar. The
   general solution is a layered approach where the absence of results
   in the first layer (DNS) leads to an automatic fallback to the next
   (search). The auto-search mechanism in Microsoft Internet Explorer
   and smart browsing in Netscape are both examples of this approach.
   Both provide a great starting point for discussing the integration of
   layered navigation services and the presentation of results from
   multiple sources at the user interface level.

   In this section, we propose a user interface model for integrating
   DNS search services within a Web browser desktop application. The
   interface is based on multiple HTML frames where results from each
   layer (possibly from multiple databases) occupy a designated frame.
   The UI is to provide a flow of results that expresses the
   architectural layering from DNS search at the user interface level.
   The architectural flow from high precision-low recall to lower
   precision-higher recall databases is expressed through a sequence of
   HTML frames ordered from left to right and top to bottom. A schematic
   browser view of that representation is depicted in the figure below.

   |                 |        L3 RESULTS         |
   |                 |---------------------------|
   |    L2 RESULTS   |                           |
   |                 |                           |
   |                 |        L4 RESULTS         |
   |                 |                           |
   |                 |                           |

   It is important to note that in the case where there are no results
   within a specific layer, the corresponding frame would not be
   displayed. However, it is crucial that the structural layout be
   maintained so that the origin of the results can be easily identified
   by end-users. For example, in the absence of layer 2 results, the
   frame would be minimized but the layer 3 or layer 4 results would not
   be rolled into the left band.

   In the case of unambiguous names, that is names with a high degree of
   uniqueness and high user expectation such as famous trademarks or
   highly qualified names, the main frame could be filled by one single
   result (destination Web page). That case corresponds to a direct
   navigation event and provides a similar user experience to a layer 1
   (DNS) name typed into the browser address bar. Note however, that
   unlike the DNS case, the left frame of layer 2 results displays
   alternate destinations for the same query input.

   For visualization purpose, a mockup of such interface can be found at and The query for that example
   corresponds to the English and Chinese equivalent query string
   Chengdu China travel service, a travel agency specialized in
   organized travel tours of the Chengdu region in China. As mentioned
   in [TC/SC], the Chinese version of this example shows the ability for
   layer 2 services to leverage the contextual information from the
   client to decide whether TC to SC normalization process should occur
   or not. In that case, the client issuing the request has specified
   that the query string is in the Chinese language and that the user
   country is mainland China. Hence, the layer 2 service matches the
   query after performing a TC to SC conversion and returns names in the
   SC script although the input query was expressed in the TC script.

   For less precise queries or incompletely qualified names, such as
   Chengdu China travel, the main frame is no longer occupied by one
   single destination page. Instead, two new sets of results are
   displayed. These two new sets of results replace what used to be the
   main frame. That main frame is now split into two horizontal frames
   of unequal size. Note that the vertical frame for layer 2 results
   still remains.

   The first and smaller of the two horizontal frames contains
   references to layer 3 services (vertical directories or yellow page
   services). In our example, these layer 3 services are specialized
   directories aggregating businesses from Beijing. Possible candidates
   for such services are chambers of commerce (geographical
   specialization) as well as local directories specialized in travel
   agency services (vertical business specialization). In other words,
   relevant layer 3 services for the specific user query are expected to
   occupy that band of results. In order to provide a simple heuristic
   for identifying such relevant services, one solution is to allow
   layer 3 services to register specialized names with layer 2 services.
   For example, in our example, the two mentioned layer 3 services would
   be displayed after registering under the categorical terms chengdu
   and travel (under two different organization classification facet
   values). From that standpoint, registration of specialized names with
   a layer 2 service provides a simple gateway mechanism to expose layer
   3 services to end-users in the context of relevant queries.

   We believe that the possibility of leveraging the layer 2 service
   name registration services to enable layer 3 references to appear
   within the query flow is an important consideration.  Indeed, the
   registration of names and key terms into a layer 2 database is likely
   to facilitate a layer 3 service to be found by a local user in need
   of the specialized service.

   The last and larger horizontal frame completes the navigation
   experience by providing a broader range of results. These results
   originate from one or many layer 4 services such as the popular
   Yahoo! search engine.

   For visualization purpose, an English as well as a Chinese mockup of
   such interface can be found at and Note that the Chinese
   version also shows the possible integration of multiple layer 4
   services through user-selectable tabs.

2.   Email integration

   For email, the DNS-Search architecture is used to resolve friendly
   email names in the form user@organization [SLS]. Note that
   traditional names in the form user@domain.tld are still resolved
   through the DNS and the mail server. In the case of an extended name
   such as user@organization, the resolution process happens in two
   consecutive steps. First, a layer 2 service is used to resolve the
   organization component. The resolution returns a descriptor for a
   service capable of resolving the user component of the name. This
   service corresponds to a specialized user name service, which is a
   layer 3 service. That service performs the second resolution step to
   resolve user@organization into a valid email address. Alternatively,
   the layer 2 service can return the LDAP URI for the server supporting
   the local organization. Since email clients already support LDAP
   servers for extended name resolutions, and since LDAP servers are
   popular in many organizations, this approach would have the advantage
   to alleviate the need for the organization to deploy a new protocol
   and server type.

   The email integration follows the same interface approach as the Web
   browser. In popular email clients, the common way to handle extended
   names is to present a search window to the user. From that window,
   the user can choose from a selection of LDAP servers and personal
   address books. The proposed interface for email leverages the
   existing search window metaphor of the mail client by integrating the
   layer 2 and 3 services within that window.

   The proposed interface implements a master-detail list view layout.
   The organization is found through a results list originating from a
   layer 2 service. Similarly to Web browsing, the list is presented on
   the left hand side of the search window. The organization results
   list can be augmented by layer 3 and layer 4 results as needed. All
   these results refer to a name server capable of resolving the user
   name component of the query within the selected organization. Once an
   organization is identified, the detail view on the right hand side of
   the search window is populated with user names matching the user
   component of the extended email address. Typically, the layer 3
   service or LDAP server for the organization is responsible for
   returning such users list.

   |                 |                                |
   |    LAYERED      |                                |
   |    ORGANIZATION |                                |
   |    RESULTS      |        USER RESULTS            |
   |    (L2, L3, L4) |        (L3, LDAP server)       |
   |                 |                                |
   |                 |                                |
   |                 |                                |

   Once the user is identified and selected, the user@organization name
   is finally resolved into a layer one address.

   For visualization purpose, a mockup of such interface can be found at as well as at The query for that example
   corresponds to the Chinese equivalent of Shi Xiaohong@Chengdu China
   Travle Service. The layer 2 engine has returned a list of organization
   specific layer 3 services (left frame) as well public LDAP servers.
   The user has selected the top results in the organization list (
   Chengdu China Travle Service) and the layer 3 service from
   Beijing Lotus Travel Advisor has returned a list of user names
   pointing to mailto URIs. 

3.   Generalization: the desktop navigation companion

   One of the most interesting aspect of the DNS-Search architecture is
   that it enables navigation across multiple types of network resources
   (company Web pages, people...), across multiple devices and across
   multiple applications. That generalized use of common names for
   accessing network resources creates the opportunity for unifying
   navigation though a specialized navigation agent. As illustrated by
   the two previous sections, the agent could be integrated within
   existing desktop applications. However, a drawback of this approach
   is that it requires the user interface of existing applications to be

   In this section, we introduce the concept of a stand-alone unified
   navigation agent. This new user agent would dwell outside of all
   desktop applications. Hence, it would alleviate the need for altering
   these applications. The new client application could be open sourced
   and ported to a wide range of operating systems in order to
   facilitate the proliferation and adoption of the new DNS search
   infrastructure. The open-source code base could also be customized by
   any layer 2 service or layer 3 service providers for their own
   purpose; the client would also be "configurable" by users to meet
   their personal needs and preferences.

   The unified navigation companion is a specialized search and
   navigation application that simplifies the discovery and access of
   multiple network resource types by leveraging the DNS search
   infrastructure. The unified navigation companion facilitates the
   lookup of names and context into multiple URIs that spawn multiple
   access protocols. However, the companion does not replace any of the
   current desktop applications. In fact, the companion does not even
   access the network resource. It only retrieves the resource physical
   addresses (in the forms of distinct URIs). The companion also
   presents contextual information about the resource (metadata) to help
   the user disambiguate among multiple choices. Eventually, the
   resource is still accessed through the existing desktop applications,
   such as the Web browser or mail client when the user selects one of
   the presented URIs in the companion results list.

   For example, in the unified navigation companion, the common name
   "Chengdu China travel service" would not only present the URL of the
   Web page (, but would also return the email
   address for requesting information from the company (e.g., the telephone number for contacting a travel
   agent in the company offices (tel: +86-010-65812445), a chat handle
   to a customer support representative, (, etc. The 
   user would simply select the desired network resource and form of
   access to the resource by clicking the corresponding URI. In turn, 
   that selection would automatically trigger the default application 
   for that resource type (Web browser for http, default mail client 
   for a mailto URI, IP telephone client for tel URI, etc). At that point,
   the companion would have performed its function.

   For visualization purpose, a mockup of such interface can be seen at (English version) and (Chinese version).

   Because layer 2 names and possibly layer 3 and layer 4 entries refer
   to physical network resources by their URI (identifiers that can
   spawn multiple protocols), it is possible to envision an independent
   desktop application for navigating to Internet resources across
   multiple applications. The pro of such approach is to enable the use
   of human friendly names across many client applications without
   requiring any of them to change.

Security Considerations

   Secure navigation through the use of common names implies a secure
   name lookup protocol. Security considerations for such protocol have
   been discussed in [CNRP]. For confidentiality and authentication,
   CNRP essentially proposes to leverage existing encryption mechanisms
   provided at the transport level. The use of XML signatures for
   encrypting or signing individual or multiple results is also
   possible. With or without CNRP, for private or paid-for services
   (e.g. health records, legal documents) that require client
   authentication, confidentiality or non-repudiation, the use of TLS
   and XML signatures provide a solid base for securely exchanging query
   and results set between the client application and the DNS search


   This draft proposes a few scenarios for integrating the layered
   naming system envisioned by John Klensin within existing desktop
   applications. This draft suggests that the emergence of a new naming
   architecture will lead to the emergence of a new class of
   applications that will in turn redefine navigation across all network
   resource types. The primary intent of this draft was not to suggest a
   standardized user interface for these applications but instead, to
   show that the proposed architectural model lends itself to very
   simple user interfaces. The authors view simplicity as an important
   consideration as it will make the deployment of the new architecture
   relatively straightforward across today's popular applications, a key
   requirement for the successful deployment of DNS search.


   [DNS-SEARCH]      Klensin, J., "A Search-based access model for the
                  DNS", work in progress, draft draft-klensin-dns-search-

   [DNS-ROLE]        Klensin, J., "Role of the Domain Name System",
                  draft-klensin-dns-role-03, work in progress, June

   [SLS]                   Mealling, M and L Daigle, "Service Lookup
                  System (SLS)", work in progress, draft-mealling-sls-

   [CNRP]               Popp, N., Mealling, N. and M. Moseley, "Common
                  Name Resolution Protocol (CNRP)", draft-ietf-cnrp-12,
                  February 2002.

   [TC/SC]              Xiaodong Lee & al. Traditional and Simplified
                  Chinese Conversion, draft-ietf-idn-tsconv-02.txt.


   Discussions with a number of people have led to this document. Especially
   some important suggestions have come from conversations with Nicolas Popp,
   John Klensin, Patrik Faltstrom, Hongyi Zhou, Shu Cao and Jinqiang Gao.

Author's Addresses

   Xiaohong SHI
   Inter China Network Software CO., Ltd.
   RM.406 He Qiao North Tower, 8A Guanghua Rd., Chaoyang Dist. Beijing, 
   Phone: +86 10 65812445 ext. 625

   Karen LIU
   Inter China Network Software CO., Ltd.
   RM.406 He Qiao North Tower, 8A Guanghua Rd., Chaoyang Dist. Beijing, 
   Phone: +86 10 65812445 ext. 619