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