As per Relevance of the word resolution, we have this rfc below:
Network Working Group N.
Request for Comments: 2972 RealNames
Category: Informational M.
Network
L.
AT&T
K.
October 2000
Context and Goals for Common Name
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document establishes the context and goals for a Common
Resolution Protocol. It defines the terminology used concerning
"Common Name" and how one might be "resolved", and establishes
distinction between "resolution" and more elaborate
mechanisms. It establishes some expected contexts for use of
Name Resolution, and the criteria for evaluating a
protocol. It also analyzes the various motivations that would
services to provide Common Name resolution for both public,
and commercial use
This document is intended as input to the formation of a Common
Resolution Protocol working group. Please send any comments
cnrp-ietf@lists.internic.net. To review the mail archives,
internic.net/archives/cnrp-ietf.html
1.
People often refer to things in the real world by a common name
phrase, e.g., a trade name, company name, or a book title.
names are sometimes easier for people to remember and enter
URLs; many people consider URLs hard to remember or type
Furthermore, because of the limited syntax of URLs, companies
individuals are finding that the ones that might be most
Popp, et al. Informational [Page 1]
RFC 2972 Context & Goals for Common Name Resolution October 2000
for their resources are already being used elsewhere and
unavailable. Common names are not URIs (Uniform
Identifiers) in that they lack the syntactic structure imposed
URIs; furthermore, unlike URNs, there is no requirement of
or persistence of the association between a common name and
resource. These common names are expected to be used primarily
humans (as opposed to machine agents).
Common name "resolution" is a process of mapping from common names
Internet resources; a Common Name Resolution Protocol (CNRP) is
network protocol used in such a process
A useful analogy for understanding the purpose and scope of
names, and CNRP, are everyday (human language) dictionaries.
cover a given language (namespace) -- perhaps a spoken language,
some specific subset (e.g., technical terms, etc). Some
give definitions, others give translations (e.g., to
languages). Different entities publish dictionaries that cover
same language -- e.g., Larousse and Collins can both publish French
language dictionaries. Thus, the dictionary publisher is the
to the resolution service provider -- the service can provide
value-add and build up name recognition for itself, but does
impede other entities from providing definitions for precisely
same strings in the language
Services are arising that offer a mapping from common names
Internet resources (e.g., as identified by a URI). These
often resolve common name categories such as company names,
names, or common keywords. Thus, such a resolution service
operate in one or a small number of categories or domains, or
expect the client to limit the resolution scope to a limited
of categories or domains. For example, the phrase "
Engineering Task Force" is a common name in the "organization
category, as is "Moby Dick" in the book category. A single
name may be associated with different data records, and more than
resolution service is expected to exist. Any common name may be
in any resolution service
Two classes of clients of such services are being built:
improvements and web accessible front-end services.
enhancements modify the "open" or "address" field of a browser
that a common name can be entered instead of a URL. Internet
sites integrate common name resolution services as a complement
search. In both cases, these may be clients of back-end
services. In the browser case, the browser must talk to a
that will resolve the common name. The search sites are accessed
Popp, et al. Informational [Page 2]
RFC 2972 Context & Goals for Common Name Resolution October 2000
a browser. In some cases, the search site may also be the back-
resolution service, but in others, the search site is a front-end
a collection of back-end services
This effort is about the creation of a protocol for
applications to communicate with common name resolution services,
exemplified in both the browser enhancement and search
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
generic search services and thus do not need to provide
Boolean query, relevance ranking or similar capabilities.
protocol is expected to be a simple, minimal interoperable core
Mechanisms for extension will be provided, so that
capabilities can be added later
Several other issues, while of importance to the deployment of
name resolution services, are outside of the resolution
itself and are not in the initial scope of the proposed effort
These include discovery and selection of resolution
providers, administration of resolution services, name registration
name ownership, and methods for creating, identifying or
unique common names
2. Key Goals for a Common Name Resolution
The key deliverable is a protocol for parameterized resolution
"Resolution" is defined as the retrieval of data associated (
priori) with descriptors that match the input request
"Parameterized" means the ability to have a multi-
descriptor both as part of the query and the response.
descriptors are attribute-value pairs. They are not required
provide unique identification, therefore 0 or more records may
returned to meet a specific input query. The protocol will define
- client requests/server responses to identify the
parameters accepted and/or required on input
- client request/server responses to identify properties to
returned in the result
- expression of parameterized input
- expression of result
- standard expression of error
Popp, et al. Informational [Page 3]
RFC 2972 Context & Goals for Common Name Resolution October 2000
To avoid creating a general search protocol with
complexity, and to keep the protocol simple enough so that
implementations will have similar behavior, the resolution
should be limited to sub-string matches against parameter values.
support full internationalization, UTF-8 encoding of strings
sub-strings is preferred
In addition, the working group should define one sample service
on this protocol -- the resolution of so-called "common names",
resolution of non-unique, registered strings to
descriptions
3. CNRP
The goal of CNRP is to create a lightweight search protocol with
simple query interface, with a focus on making the common case
substring search with a single result most efficient. In addition
efficient support for keyed value search is important. Each key is
named meta property of the resource (e.g. category, language
geographical region.). Some of these properties could
standardized (e.g. the common name property). The goal is to
partial specification of query parameters and even partial and
matches on names. CNRP is intended to be simpler than LDAP
simple applications
Besides simplicity, the CNRP protocol should be consistent
efficient implementation of a simple and intuitive user interface
The emphasis on the common name as the common denominator to find
wide range of resources reduces the UI to its minimal expression (
user types a few words in a text box and presses enter).
CNRP should provide interoperability with multiple common
databases (section 4 presents many examples of such databases).
query interface should be extensible and customizable to the
needs of a specific type of resolution service. However, the
for interoperability across databases and resolution
combined with the need to ensure the scalability of search (
millions of names from multiple providers) have lead this group
consider the explicit requirement of supporting categories in CNRP
This requirement is discussed further in section 5.
4. Example of common name
Commercial companies have already developed and deployed common
resolution services such as RealNames (http://www.realnames.com)
NetWords (http://www.netword.com). These commercial
are mainly focused on trade names, such as company names, brands
Popp, et al. Informational [Page 4]
RFC 2972 Context & Goals for Common Name Resolution October 2000
trademarks. These services constitute a concrete example of
name namespaces implementation and are useful to understand the
of the CNRP effort
CNRP is also directly targeted at directory service providers.
is relevant to these services to increase their reach
integration into larger Web sites such as the search portals.
example, IAtlas has developed a directory service for businesses
it distributes through its Web site and Inktomi. IAtlas
immediately leverage CNRP to distribute their service through
external distribution partners
Directory services must not be confused with search engines
Directory services use highly structured information to identify
resource. This information is external to the actual resource and
called metadata. In contrast, search engines mainly rely on
content of the resource (e.g. the text of a Web page).
CNRP plays well with directory services that present a critical
of information about the resource in the form of a
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
cases, the common name is the natural property for users to
the resource. The common name is always simple and intuitive: it
no syntax, it is multilingual, memorable and can often be guessed
The following list is intended to put in prospective the wide
of applications for CNRP
- Business directories (SEC, NASDAQ, E*Trade, .). The resource
company information (address, products, SEC filings, stock quotes
etc.). The common name is the company name
- White pages (BigFoot, WhoWhere, Switchboard, ...): The resource
person (current address, telephone numbers, email addresses
employer, ...). The common name is a last name, a telephone
or an email address
- 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
title, an artist's name. The common name is typically the title
a publication
Popp, et al. Informational [Page 5]
RFC 2972 Context & Goals for Common Name Resolution October 2000
- Entertainment directories: The resource is an event (a movie,
concert, a TV show). The common name is the name or a
for the event, the movie title, a rock band name, a show
- Yellow pages services: Here again, the resource can be
diverse: a house for sale, a restaurant, a car dealership or
type of establishment or service that can be found in
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
headline
- Vertical directories: the DNS TLD categories, the ISO
codes
5. Private and public
A set of common names within a category (books, news, businesses
etc.) is called a common name "namespace". The term "namespace"
refers to the set of names. It does not encompass the bindings
associations between a name and data about the name (such as
resource, identified by a URI). Such bindings might be created
maintained by a common name resolution services. Resolution
may create binding that are relevant for the type of service
they offer
It is useful to distinguish between "private" and "public
namespaces. A namespace is private if owned by an authority
controls the right to assign the names. A namespace is private
if the right to assign those names is held by a neutral party
A namespace is public when not controlled by any single authority
resolution provider. Assignment of the names is distributed
However, it is reasonable to expect that people who assign names
tend to pick names that have a minimum of collisions. For some
these namespaces, there will even be mechanisms to
duplicate assignment, but all of them are inherently ambiguous
Public namespaces are not controlled. Examples of public
are
- Titles of books, movies, songs, poems, short stories, plays,
- Place
- Street
- People's
Popp, et al. Informational [Page 6]
RFC 2972 Context & Goals for Common Name Resolution October 2000
Because these namespaces are unbounded and open to any types of
assignment, they will have scalability problems. To support
namespaces, CNRP must provide at least one standard mechanism
filter a large list of related results. A filtering mechanism
allow the user to narrow the search further down to a smaller
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
categorization system (whether flat or hierarchical).
categories constitute an efficient search filter, defining
vocabularies for common name categories is beyond the scope of
protocol design. The protocol design for CNRP should not require
standardized taxonomy for categories in order to be effective.
example, CNRP resolution could use free-form keywords; the end-
would use these keywords as part of the query. Each service
then be responsible for mapping the keywords to zero, one or
categories in their own classification. The keywords would
classification independent and different services could use
categorization schemes without compromising interoperability.
would then be up to the service to provide its own mapping.
example, let us assume that one namespace is resolving names
the category: "Hobby & Interests > collecting > antique > books".
Assume that a second namespace has decided to organize the names
similar resources under the classification: "Arts > Humanities >
Literature > History of Books and Printing > antiques". Although
two taxonomies are different, a CNRP query
category_keywords = "antique books" would allow each service
identify the appropriate category. This mechanism may ensure
the two result lists are small and coherent enough to be merged
one unique result set. It is important to note that this
would work whether the classification is hierarchical or not
Although this suggestion has merit, it is fair to say that it
unproven. In particular, it is unclear that the category_
property would guarantee full interoperability across
services. In any case, free form keywords for specifying
is just one of several possible ways of limiting the scope of
query. Although the specific mechanisms are not agreed upon a
time, CNRP will provide at least one standard mechanism for
scope
6. Distributors/integrators of common name resolution
We anticipate two main categories of distributors for
namespaces. The first category is made of the Web portals such
search engines (Yahoo, MSN, Lycos, Infoseek, AltaVista, ...).
Popp, et al. Informational [Page 7]
RFC 2972 Context & Goals for Common Name Resolution October 2000
common name resolution service will typically address only one
specialized aspect of search (company names or book titles or
names, ..). This type of focused lookup service is a
complement to generic search. Hence, portals are likely to
several types of common name services. CNRP solves the
problem of integrating multiple external independent services
one Web site. Today, the lack of standardization in
requirements and query interface leads to loose integration (co
branded pages hosted on virtual domains) or maintenance
(periodical data dumps). CNRP is aimed at solving some of
issues. CNRP facilitates the deployment of embedded services
creating a common interface to all common name services
The second category of distributors is made of the Web
companies. Netscape's smart
(http://home.netscape.com/communicator/v4.5/index.html#smart)
Microsoft's IE5 auto-search
(http://www.microsoft.com/windows/Ie/Features/AutoSearch/default.asp
demonstrate that the two dominant Web browser companies
the value of navigation and search from the command line of
browser. It is very clear how this command line could be used as
main user interface to common name resolution services through CNRP
In many ways, it is actually the most natural user interface
resolve a common name. For this strategic component of the browser'
user interface to remain truly open to all common name
services, it is key that there exists a standard resolution
(and a service discovery mechanism). CNRP will give users access
the largest selection of services and providers and the ability
select a specific resolution service over another. To preserve
user from proprietary implementations, the existence of CNRP is
prerequisite
7. Example of cost recovery models for maintenance of
The following discussion of possible business models for common
namespaces is intended to prove that they are commercially viable
hence that CNRP will be used in the market place. This
presents 5 different cost recovery models
a. Licensing the lookup
In such model, the owner of the database owner licenses the
and the resolution service to a portal. This is a proven model
For example, Looksmart (a directory service) recently licensed
their data to MSN. Another possibility is to sell access to
service directly to the user. For some vertical type of
Popp, et al. Informational [Page 8]
RFC 2972 Context & Goals for Common Name Resolution October 2000
names service (e.g. patent search), it is also conceivable that
specific type of users (e.g., lawyers) would be willing to pay
accessing a precise resolution service
b. Sharing revenue generated by banner
In this model, the database owner licenses his
(data and resolution service) to a portal. Prepaid banner ads
placed on the result pages. The revenue is shared between
resolution service provider and the portal that hosts the pages
c. Selling the names (charge the customer a fee for subscribing
name
This is a proven business model as well (NSI, GOTO, RealNames
Netword, for of the name has a large user reach (search
sell keywords for instance).
d. Value added
Another model is to build a common name as a free added
service in order to make a core service more compelling to users
For example, Amazon.com could create a common name namespace
book titles and make it freely available to its users. Amazon.
would not make any money from the resolution service per se
However, it would indirectly since the service would help
users find hence buy more books from Amazon.com
e. "Some-strings-attached" free
A namespace may give users a name for free in exchange
something else (capturing the user's profile that can be sold
merchants, capturing the user's email address in order to
advertising emails, etc.).
8. Security and Intellectual Property Rights
This document describes the goals of a system for multi-
Internet identifiers. This document does not discuss resolution
thus questions of secure or authenticated resolution mechanisms
out of scope. It does not address means of validating the
or authenticating the source or provenance of Common Names.
regarding intellectual property rights associated with
identified by the various Common Names are also beyond the scope
this document, as are questions about rights to the databases
might be used to construct resolvers
Popp, et al. Informational [Page 9]
RFC 2972 Context & Goals for Common Name Resolution October 2000
9. Authors'
Larry
AT&T
75 Willow
Menlo Park, CA 94025
Phone: +1 650 463 7059
EMail: LMM@acm.
http://larry.masinter.
Michael
Network
505 Huntmar Park
Herndon, VA 22070
Phone: (770) 935-5492
Fax: (703) 742-9552
EMail: michaelm@netsol.
Nicolas
RealNames
2 Circle Star
San Carlos, CA 94070-1350
Phone: 1-650-298-5549
EMail: nico@realnames.
Karen
MIT Laboratory for Computer
545 Technology Sq
Cambridge, MA 02139
Phone: +1 617 253 6006
EMail: sollins@lcs.mit.
Popp, et al. Informational [Page 10]
RFC 2972 Context & Goals for Common Name Resolution October 2000
10. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Popp, et al. Informational [Page 11]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
