doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc2972.txt b/doc/rfc/rfc2972.txt
new file mode 100644
index 0000000..89dd973
--- /dev/null
+++ b/doc/rfc/rfc2972.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                            N. Popp
+Request for Comments: 2972                         RealNames Corporation
+Category: Informational                                      M. Mealling
+                                                       Network Solutions
+                                                             L. Masinter
+                                                               AT&T Labs
+                                                              K. Sollins
+                                                                     MIT
+                                                            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.
+
+Abstract
+
+   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
+   cnrp-ietf@lists.internic.net.  To review the mail archives, see
+   <http://lists.internic.net/archives/cnrp-ietf.html>
+
+1. Introduction
+
+   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
+
+
+
+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 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
+
+
+
+
+
+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-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
+
+   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
+
+
+
+
+
+Popp, et al.                 Informational                      [Page 3]
+
+RFC 2972       Context & Goals for Common Name Resolution   October 2000
+
+
+   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
+
+   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
+
+   Commercial companies have already developed and deployed common name
+   resolution services such as RealNames (http://www.realnames.com) and
+   NetWords (http://www.netword.com).  These commercial implementations
+   are mainly focused on trade names, such as company names, brands and
+
+
+
+
+Popp, et al.                 Informational                      [Page 4]
+
+RFC 2972       Context & Goals for Common Name Resolution   October 2000
+
+
+   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.
+
+   - 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.
+
+   - 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.
+
+
+
+
+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, 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.
+
+5. Private and public namespaces
+
+   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
+
+
+
+
+
+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 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.
+
+   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
+
+   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
+
+
+
+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 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
+   (http://home.netscape.com/communicator/v4.5/index.html#smart) and
+   Microsoft's IE5 auto-search features
+   (http://www.microsoft.com/windows/Ie/Features/AutoSearch/default.asp)
+   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
+
+   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
+
+      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
+
+
+
+
+
+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 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
+
+      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)
+
+      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
+
+      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, Amazon.com could create a common name namespace of
+      book titles and make it freely available to its users.  Amazon.com
+      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 Amazon.com.
+
+   e. "Some-strings-attached" free names
+
+      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
+
+   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.
+
+
+
+
+
+Popp, et al.                 Informational                      [Page 9]
+
+RFC 2972       Context & Goals for Common Name Resolution   October 2000
+
+
+9. Authors' Addresses
+
+   Larry Masinter
+   AT&T Labs
+   75 Willow Road
+   Menlo Park, CA 94025
+
+   Phone: +1 650 463 7059
+   EMail: LMM@acm.org
+   http://larry.masinter.net
+
+
+   Michael Mealling
+   Network Solutions
+   505 Huntmar Park Drive
+   Herndon, VA 22070
+
+   Phone: (770) 935-5492
+   Fax: (703) 742-9552
+   EMail: michaelm@netsol.com
+
+
+   Nicolas Popp
+   RealNames Corporation
+   2 Circle Star Way
+   San Carlos, CA  94070-1350
+
+   Phone: 1-650-298-5549
+   EMail: nico@realnames.com
+
+
+   Karen Sollins
+   MIT Laboratory for Computer Science
+   545 Technology Sq.
+   Cambridge, MA 02139
+
+   Phone: +1 617 253 6006
+   EMail: sollins@lcs.mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+Popp, et al.                 Informational                     [Page 10]
+
+RFC 2972       Context & Goals for Common Name Resolution   October 2000
+
+
+10. Full Copyright Statement
+
+   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.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Popp, et al.                 Informational                     [Page 11]
+