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- 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract 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 Introduction 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 Introduction 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 space. 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 http://www.3721.com/ietf/en/example1.htm and http://www.3721.com/ietf/cn/example1.htm. 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 http://www.3721.com/ietf/en/example2.htm and http://www.3721.com/ietf/cn/example2.htm. 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 http://www.3721.com/ietf/en/example3.htm as well as at http://www.3721.com/ietf/cn/example3.htm. 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 changed. 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 (http://www.cts.com.cn/), but would also return the email address for requesting information from the company (e.g. mailto:sales@cts.com.cn), the telephone number for contacting a travel agent in the company offices (tel: +86-010-65812445), a chat handle to a customer support representative, (help@@cts.com.cn), 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 http://www.3721.com/ietf/en/example4.htm (English version) and http://www.3721.com/ietf/cn/example4.htm (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 services. Conclusion 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. References [DNS-SEARCH] Klensin, J., "A Search-based access model for the DNS", work in progress, draft draft-klensin-dns-search- 04.txt [DNS-ROLE] Klensin, J., "Role of the Domain Name System", draft-klensin-dns-role-03, work in progress, June 2002. [SLS] Mealling, M and L Daigle, "Service Lookup System (SLS)", work in progress, draft-mealling-sls- 01.txt [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. Acknowlegement 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, P.R.China 100026 Phone: +86 10 65812445 ext. 625 E-mail: sxh@3721.com Karen LIU Inter China Network Software CO., Ltd. RM.406 He Qiao North Tower, 8A Guanghua Rd., Chaoyang Dist. Beijing, P.R.China 100026 Phone: +86 10 65812445 ext. 619 E-mail: karen@3721.com