rfc2972.txt

中、英文RFC文档大全打包下载完全版 .

   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: [phone]
   EMail: [e-mail]
   http://larry.masinter.net


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

   Phone: [phone]
   Fax: [phone]
   EMail: [e-mail]


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

   Phone: [phone]
   EMail: [e-mail]


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

   Phone: [phone]
   EMail: [e-mail]













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]