Network Working Group                                            N. Popp
Request for Comments: 2972                         RealNames Corporation
Category: Informational                                      M. Mealling
                                                       Network Solutions
                                                             L. Masinter
                                                               AT&T Labs
                                                              K. Sollins
                                                            October 2000
Network Working Group                                            N. Popp
Request for Comments: 2972                         RealNames Corporation
Category: Informational                                      M. Mealling
                                                       Network Solutions
                                                             L. Masinter
                                                               AT&T Labs
                                                              K. Sollins
                                                            October 2000

Context and Goals for Common Name Resolution


Status of this Memo


This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.


Copyright Notice


Copyright (C) The Internet Society (2000). All Rights Reserved.




This document establishes the context and goals for a Common Name Resolution Protocol. It defines the terminology used concerning a "Common Name" and how one might be "resolved", and establishes the distinction between "resolution" and more elaborate search mechanisms. It establishes some expected contexts for use of Common Name Resolution, and the criteria for evaluating a successful protocol. It also analyzes the various motivations that would cause services to provide Common Name resolution for both public, private and commercial use.


   This document is intended as input to the formation of a Common Name
   Resolution Protocol working group.  Please send any comments to  To review the mail archives, see
   This document is intended as input to the formation of a Common Name
   Resolution Protocol working group.  Please send any comments to  To review the mail archives, see
1. Introduction
1. 介绍

People often refer to things in the real world by a common name or phrase, e.g., a trade name, company name, or a book title. These names are sometimes easier for people to remember and enter than URLs; many people consider URLs hard to remember or type. Furthermore, because of the limited syntax of URLs, companies and individuals are finding that the ones that might be most reasonable


for their resources are already being used elsewhere and therefore unavailable. Common names are not URIs (Uniform Resource Identifiers) in that they lack the syntactic structure imposed by URIs; furthermore, unlike URNs, there is no requirement of uniqueness or persistence of the association between a common name and a resource. These common names are expected to be used primarily by humans (as opposed to machine agents).


Common name "resolution" is a process of mapping from common names to Internet resources; a Common Name Resolution Protocol (CNRP) is a network protocol used in such a process.


A useful analogy for understanding the purpose and scope of common names, and CNRP, are everyday (human language) dictionaries. These cover a given language (namespace) -- perhaps a spoken language, or some specific subset (e.g., technical terms, etc). Some dictionaries give definitions, others give translations (e.g., to other languages). Different entities publish dictionaries that cover the same language -- e.g., Larousse and Collins can both publish French-language dictionaries. Thus, the dictionary publisher is the analog to the resolution service provider -- the service can provide a value-add and build up name recognition for itself, but does not impede other entities from providing definitions for precisely the same strings in the language.


Services are arising that offer a mapping from common names to Internet resources (e.g., as identified by a URI). These services often resolve common name categories such as company names, trade names, or common keywords. Thus, such a resolution service may operate in one or a small number of categories or domains, or may expect the client to limit the resolution scope to a limited number of categories or domains. For example, the phrase "Internet Engineering Task Force" is a common name in the "organization" category, as is "Moby Dick" in the book category. A single common name may be associated with different data records, and more than one resolution service is expected to exist. Any common name may be used in any resolution service.


Two classes of clients of such services are being built: browser improvements and web accessible front-end services. Browser enhancements modify the "open" or "address" field of a browser so that a common name can be entered instead of a URL. Internet search sites integrate common name resolution services as a complement to search. In both cases, these may be clients of back-end resolution services. In the browser case, the browser must talk to a service that will resolve the common name. The search sites are accessed via


a browser. In some cases, the search site may also be the back-end resolution service, but in others, the search site is a front-end to a collection of back-end services.


This effort is about the creation of a protocol for client applications to communicate with common name resolution services, as exemplified in both the browser enhancement and search site paradigms. Although the protocol's primary function is resolution, it is intended to address the issues of internationalization, authentication and privacy as well. Name resolution services are not generic search services and thus do not need to provide complex Boolean query, relevance ranking or similar capabilities. The protocol is expected to be a simple, minimal interoperable core. Mechanisms for extension will be provided, so that additional capabilities can be added later.


Several other issues, while of importance to the deployment of common name resolution services, are outside of the resolution protocol itself and are not in the initial scope of the proposed effort. These include discovery and selection of resolution service providers, administration of resolution services, name registration, name ownership, and methods for creating, identifying or insuring unique common names.


2. Key Goals for a Common Name Resolution Protocol
2. 通用名称解析协议的关键目标

The key deliverable is a protocol for parameterized resolution. "Resolution" is defined as the retrieval of data associated (a priori) with descriptors that match the input request. "Parameterized" means the ability to have a multi-component descriptor both as part of the query and the response. These descriptors are attribute-value pairs. They are not required to provide unique identification, therefore 0 or more records may be returned to meet a specific input query. The protocol will define:


- client requests/server responses to identify the specific parameters accepted and/or required on input requests

- 客户端请求/服务器响应,以确定输入请求中接受和/或需要的特定参数

- client request/server responses to identify properties to be returned in the result set

- 用于标识要在结果集中返回的属性的客户端请求/服务器响应

- expression of parameterized input query

- 参数化输入查询的表达式

- expression of result sets

- 结果集的表示

- standard expression of error conditions

- 误差条件的标准表达式

To avoid creating a general search protocol with unbounded complexity, and to keep the protocol simple enough so that different implementations will have similar behavior, the resolution protocol should be limited to sub-string matches against parameter values. To support full internationalization, UTF-8 encoding of strings and sub-strings is preferred.


In addition, the working group should define one sample service based on this protocol -- the resolution of so-called "common names", or resolution of non-unique, registered strings to resource descriptions.


3. CNRP goals
3. CNRP目标

The goal of CNRP is to create a lightweight search protocol with a simple query interface, with a focus on making the common case of substring search with a single result most efficient. In addition, efficient support for keyed value search is important. Each key is a named meta property of the resource (e.g. category, language, geographical region.). Some of these properties could be standardized (e.g. the common name property). The goal is to support partial specification of query parameters and even partial and fuzzy matches on names. CNRP is intended to be simpler than LDAP for simple applications.


Besides simplicity, the CNRP protocol should be consistent with efficient implementation of a simple and intuitive user interface. The emphasis on the common name as the common denominator to find a wide range of resources reduces the UI to its minimal expression (the user types a few words in a text box and presses enter).


CNRP should provide interoperability with multiple common name databases (section 4 presents many examples of such databases). The query interface should be extensible and customizable to the specific needs of a specific type of resolution service. However, the need for interoperability across databases and resolution services combined with the need to ensure the scalability of search (across millions of names from multiple providers) have lead this group to consider the explicit requirement of supporting categories in CNRP. This requirement is discussed further in section 5.


4. Example of common name namespaces
4. 通用名称空间示例
   Commercial companies have already developed and deployed common name
   resolution services such as RealNames ( and
   NetWords (  These commercial implementations
   are mainly focused on trade names, such as company names, brands and
   Commercial companies have already developed and deployed common name
   resolution services such as RealNames ( and
   NetWords (  These commercial implementations
   are mainly focused on trade names, such as company names, brands and

trademarks. These services constitute a concrete example of common name namespaces implementation and are useful to understand the scope of the CNRP effort.


CNRP is also directly targeted at directory service providers. CNRP is relevant to these services to increase their reach through integration into larger Web sites such as the search portals. For example, IAtlas has developed a directory service for businesses that it distributes through its Web site and Inktomi. IAtlas could immediately leverage CNRP to distribute their service through their external distribution partners.


Directory services must not be confused with search engines. Directory services use highly structured information to identify a resource. This information is external to the actual resource and is called metadata. In contrast, search engines mainly rely on the content of the resource (e.g. the text of a Web page).


CNRP plays well with directory services that present a critical piece of information about the resource in the form of a textual identifier, a title or a terse description (the common name). Numerous examples come instantly to mind: company names, book titles, people names, songs, ISBNs, and social security numbers. In all cases, the common name is the natural property for users to lookup the resource. The common name is always simple and intuitive: it has no syntax, it is multilingual, memorable and can often be guessed.


The following list is intended to put in prospective the wide range of applications for CNRP:


- Business directories (SEC, NASDAQ, E*Trade, .). The resource is company information (address, products, SEC filings, stock quotes, etc.). The common name is the company name.

- 业务目录(SEC、纳斯达克、E*Trade等)。资源是公司信息(地址、产品、SEC文件、股票报价等)。通用名称是公司名称。

- White pages (BigFoot, WhoWhere, Switchboard, ...): The resource a person (current address, telephone numbers, email addresses, employer, ...). The common name is a last name, a telephone number or an email address.

- 白页(大脚怪、whohere、总机等):一个人的资源(当前地址、电话号码、电子邮件地址、雇主等)。通用名是姓氏、电话号码或电子邮件地址。

- E-commerce directories: The resource is a product for sale (car, house, furniture, actually almost any type of consumption item). The common name is a brand name or a description.

- 电子商务目录:资源是一种销售产品(汽车、房子、家具,实际上几乎是任何类型的消费品)。通用名称是一个品牌名称或描述。

- Publishing directories: The resource is one of many things: a book, a poem, a CD, an MP3 download. The common name is an ISBN, a song title, an artist's name. The common name is typically the title of a publication.

- 出版目录:资源是很多东西之一:一本书,一首诗,一张CD,一个MP3下载。常见的名字是ISBN,一首歌的名字,一个艺术家的名字。通用名称通常是出版物的标题。

- Entertainment directories: The resource is an event (a movie, a concert, a TV show). The common name is the name or a description for the event, the movie title, a rock band name, a show.

- 娱乐目录:资源是一个事件(电影、音乐会、电视节目)。通用名称是事件的名称或描述、电影标题、摇滚乐队名称、演出。

- Yellow pages services: Here again, the resource can be very diverse: a house for sale, a restaurant, a car dealership or other type of establishment or service that can be found in the traditional yellow pages. The common name can be a street address, the name of a business, or a description.

- 黄页服务:在这里,资源可以非常多样化:出售房屋、餐厅、汽车经销商或其他类型的机构或服务,可以在传统的黄页中找到。通用名称可以是街道地址、企业名称或描述。

- News feeds: The resource is a press article. The common name is the headline.

- 新闻提要:资源是一篇新闻文章。通用名称是标题。

- Vertical directories: the DNS TLD categories, the ISO country codes.

- 垂直目录:DNS TLD类别、ISO国家代码。

5. Private and public namespaces
5. 私有和公共名称空间

A set of common names within a category (books, news, businesses, etc.) is called a common name "namespace". The term "namespace" only refers to the set of names. It does not encompass the bindings or associations between a name and data about the name (such as a resource, identified by a URI). Such bindings might be created and maintained by a common name resolution services. Resolution services may create binding that are relevant for the type of service that they offer.


It is useful to distinguish between "private" and "public" namespaces. A namespace is private if owned by an authority that controls the right to assign the names. A namespace is private even if the right to assign those names is held by a neutral party.


A namespace is public when not controlled by any single authority or resolution provider. Assignment of the names is distributed. However, it is reasonable to expect that people who assign names will tend to pick names that have a minimum of collisions. For some of these namespaces, there will even be mechanisms to discourage duplicate assignment, but all of them are inherently ambiguous. Public namespaces are not controlled. Examples of public namespaces are:


- Titles of books, movies, songs, poems, short stories, plays, or compilations - Place names - Street names - People's names

- 书籍、电影、歌曲、诗歌、短篇小说、戏剧或汇编的标题-地名-街道名-人名

Because these namespaces are unbounded and open to any types of name assignment, they will have scalability problems. To support these namespaces, CNRP must provide at least one standard mechanism to filter a large list of related results. A filtering mechanism must allow the user to narrow the search further down to a smaller result set, because the common name alone may not be enough.


One possible search filter is related to the notion of categories. Because categories create a structure to organize named resources, large resolution services are likely to support some sort of categorization system (whether flat or hierarchical). Although categories constitute an efficient search filter, defining standard vocabularies for common name categories is beyond the scope of the protocol design. The protocol design for CNRP should not require a standardized taxonomy for categories in order to be effective. For example, CNRP resolution could use free-form keywords; the end-user would use these keywords as part of the query. Each service would then be responsible for mapping the keywords to zero, one or many categories in their own classification. The keywords would remain classification independent and different services could use different categorization schemes without compromising interoperability. It would then be up to the service to provide its own mapping. For example, let us assume that one namespace is resolving names under the category: "Hobby & Interests > collecting > antique > books". Assume that a second namespace has decided to organize the names of similar resources under the classification: "Arts > Humanities > Literature > History of Books and Printing > antiques". Although the two taxonomies are different, a CNRP query specifying category_keywords = "antique books" would allow each service to identify the appropriate category. This mechanism may ensure that the two result lists are small and coherent enough to be merged into one unique result set. It is important to note that this approach would work whether the classification is hierarchical or not.

一个可能的搜索过滤器与类别的概念有关。因为类别创建了一个组织命名资源的结构,所以大型解析服务可能支持某种分类系统(无论是平面的还是层次的)。虽然类别构成了一个有效的搜索过滤器,但为通用名称类别定义标准词汇表超出了协议设计的范围。为了有效,CNRP的协议设计不应要求对类别进行标准化分类。例如,CNRP解析可以使用自由形式的关键字;最终用户将使用这些关键字作为查询的一部分。然后,每个服务将负责将关键字映射到零、一个或多个类别。关键字将保持分类独立,不同的服务可以使用不同的分类方案,而不会影响互操作性。然后由服务提供自己的映射。例如,让我们假设一个名称空间正在解析类别下的名称:“爱好和兴趣>收藏>古董>书籍”。假设第二个名称空间已决定将类似资源的名称组织在分类下:“艺术>人文>文学>书籍和印刷史>古董”。尽管这两种分类法不同,但指定category_keywords=“antique books”的CNRP查询将允许每个服务识别适当的类别。这种机制可以确保两个结果列表足够小和连贯,可以合并到一个唯一的结果集中。重要的是要注意,无论分类是否分层,这种方法都会起作用。

Although this suggestion has merit, it is fair to say that it remains unproven. In particular, it is unclear that the category_keywords property would guarantee full interoperability across resolution services. In any case, free form keywords for specifying categories is just one of several possible ways of limiting the scope of a query. Although the specific mechanisms are not agreed upon a this time, CNRP will provide at least one standard mechanism for limiting scope.


6. Distributors/integrators of common name resolution services
6. 通用名称解析服务的分销商/集成商

We anticipate two main categories of distributors for common namespaces. The first category is made of the Web portals such as search engines (Yahoo, MSN, Lycos, Infoseek, AltaVista, ...). A


common name resolution service will typically address only one very specialized aspect of search (company names or book titles or people names, ..). This type of focused lookup service is a useful complement to generic search. Hence, portals are likely to integrate several types of common name services. CNRP solves the difficult problem of integrating multiple external independent services within one Web site. Today, the lack of standardization in performance requirements and query interface leads to loose integration (co-branded pages hosted on virtual domains) or maintenance problems (periodical data dumps). CNRP is aimed at solving some of these issues. CNRP facilitates the deployment of embedded services by creating a common interface to all common name services.


The second category of distributors is made of the Web browser companies. Netscape's smart browsing ( and Microsoft's IE5 auto-search features ( demonstrate that the two dominant Web browser companies understand the value of navigation and search from the command line of the browser. It is very clear how this command line could be used as the main user interface to common name resolution services through CNRP. In many ways, it is actually the most natural user interface to resolve a common name. For this strategic component of the browser's user interface to remain truly open to all common name resolution services, it is key that there exists a standard resolution protocol (and a service discovery mechanism). CNRP will give users access to the largest selection of services and providers and the ability to select a specific resolution service over another. To preserve the user from proprietary implementations, the existence of CNRP is a prerequisite.


7. Example of cost recovery models for maintenance of namespaces
7. 维护名称空间的成本回收模型示例

The following discussion of possible business models for common name namespaces is intended to prove that they are commercially viable, hence that CNRP will be used in the market place. This section presents 5 different cost recovery models.


a. Licensing the lookup service

a. 授权查找服务

In such model, the owner of the database owner licenses the data and the resolution service to a portal. This is a proven model. For example, Looksmart (a directory service) recently licensed all their data to MSN. Another possibility is to sell access to the service directly to the user. For some vertical type of common


names service (e.g. patent search), it is also conceivable that a specific type of users (e.g., lawyers) would be willing to pay for accessing a precise resolution service.


b. Sharing revenue generated by banner advertising

b. 分享横幅广告产生的收入

In this model, the database owner licenses his infrastructure (data and resolution service) to a portal. Prepaid banner ads are placed on the result pages. The revenue is shared between the resolution service provider and the portal that hosts the pages.


c. Selling the names (charge the customer a fee for subscribing a name)

c. 出售姓名(向客户收取订阅姓名的费用)

This is a proven business model as well (NSI, GOTO, RealNames, Netword, for of the name has a large user reach (search engines sell keywords for instance).


d. Value added service

d. 增值服务

Another model is to build a common name as a free added value service in order to make a core service more compelling to users. For example, could create a common name namespace of book titles and make it freely available to its users. would not make any money from the resolution service per se. However, it would indirectly since the service would help the users find hence buy more books from


e. "Some-strings-attached" free names

e. “附加某些字符串”自由名称

A namespace may give users a name for free in exchange for something else (capturing the user's profile that can be sold to merchants, capturing the user's email address in order to send advertising emails, etc.).


8. Security and Intellectual Property Rights Considerations
8. 安全和知识产权方面的考虑

This document describes the goals of a system for multi-valued Internet identifiers. This document does not discuss resolution; thus questions of secure or authenticated resolution mechanisms are out of scope. It does not address means of validating the integrity or authenticating the source or provenance of Common Names. Issues regarding intellectual property rights associated with objects identified by the various Common Names are also beyond the scope of this document, as are questions about rights to the databases that might be used to construct resolvers.


9. Authors' Addresses
9. 作者地址

Larry Masinter AT&T Labs 75 Willow Road Menlo Park, CA 94025

加利福尼亚州门罗公园柳树路75号Larry Masinter AT&T实验室,邮编94025

   Phone: +1 650 463 7059
   Phone: +1 650 463 7059

Michael Mealling Network Solutions 505 Huntmar Park Drive Herndon, VA 22070


Phone: (770) 935-5492 Fax: (703) 742-9552 EMail:


Nicolas Popp RealNames Corporation 2 Circle Star Way San Carlos, CA 94070-1350

Nicolas Popp RealNames Corporation 2 Circle Star Way San Carlos,加利福尼亚州94070-1350

Phone: 1-650-298-5549 EMail:


Karen Sollins MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139


   Phone: +1 617 253 6006
   Phone: +1 617 253 6006
10. Full Copyright Statement
10. 完整版权声明

Copyright (C) The Internet Society (2000). All Rights Reserved.


This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.


The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.






Funding for the RFC Editor function is currently provided by the Internet Society.