rfc1588.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,478 行 · 第 1/5 页

Network Working Group                                          J. Postel
Request for Comments: 1588                                   C. Anderson
Category: Informational                                              ISI
                                                           February 1994


                       WHITE PAGES MEETING REPORT



STATUS OF THIS MEMO

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

INTRODUCTION

   This report describes the results of a meeting held at the November
   IETF (Internet Engineering Task Force) in Houston, TX, on November 2,
   1993, to discuss the future of and approaches to a white pages
   directory services for the Internet.

   As proposed to the National Science Foundation (NSF), USC/Information
   Sciences Institute (ISI) conducted the meeting to discuss the
   viability of the X.500 directory as a practical approach to providing
   white pages service for the Internet in the near future and to
   identify and discuss any alternatives.

   An electronic mail mailing list was organized and discussions were
   held via email for two weeks prior to the meeting.

1. EXECUTIVE SUMMARY

   This report is organized around four questions:

   1) What functions should a white pages directory perform?

      There are two functions the white pages service must provide:
      searching and retrieving.

      Searching is the ability to find people given some fuzzy
      information about them.  Such as "Find the Postel in southern
      California".  Searches may often return a list of matches.

      While the idea of indexing has been around for some time, such as
      the IN-ADDR tree in the Domain Name System (DNS), a new
      acknowledgment of its importance has emerged from these



Postel & Anderson                                               [Page 1]

RFC 1588                   White Pages Report              February 1994


      discussions.  Users want fast searching across the distributed
      database on attributes different from the database structure.
      Pre-computed indices satisfy this desire, though only for
      specified searches.

      Retrieval is obtaining additional information associated with a
      person, such as an address, telephone number, email mailbox, or
      security certificate.

      Security certificates (a type of information associated with an
      individual) are essential for the use of end-to-end
      authentication, integrity, and privacy in Internet applications.
      The development of secure applications in the Internet is
      dependent on a directory system for retrieving the security
      certificate associated with an individual.  For example, the
      privacy enhanced electronic mail (PEM) system has been developed
      and is ready to go into service, and is now hindered by the lack
      of an easily used directory of security certificates.  An open
      question is whether or not such a directory needs to be internally
      secure.

   2) What approaches will provide us with a white pages directory?

      It is evident that there are and will be several technologies in
      use.  In order to provide a white pages directory service that
      accommodates multiple technologies, we should promote
      interoperation and work toward a specification of the simplest
      common communication form that is powerful enough to provide the
      necessary functionality.  This "common ground" approach aims to
      provide the ubiquitous WPS (White Pages Service) with a high
      functionality and a low entry cost.

   3) What are the problems to be overcome?

      It must be much easier to be part of the Internet white pages than
      to bring up a X.500 DSA (Directory Service Agent), yet we must
      make good use of the already deployed X.500 DSAs.  Simpler white
      pages services (such as Whois++) must be defined to promote
      multiple implementations.  To promote reliable operation, there
      must be some central management of the X.500 system.  A common
      naming scheme must be identified and documented.  A set of index-
      servers, and indexing techniques, must be developed.  The storage
      and retrieval of security certificates must be provided.








Postel & Anderson                                               [Page 2]

RFC 1588                   White Pages Report              February 1994


   4) What should the deployment strategy be?

      Some central management must be provided, and easy to use user
      interfaces (such as the Gopher "gateway"), must be widely
      deployed.  The selection of a naming scheme must be documented.
      We should capitalize on the existing infrastructure of already
      deployed X.500 DSAs.  The "common ground" model should be adopted.
      A specification of the simplest common communication form must be
      developed.  Information about how to set up a new server (of
      whatever kind) in "cookbook" form should be made available.

   RECOMMENDATIONS

    1.  Adopt the common ground approach.  Encourage multiple client and
        server types, and the standardization of an interoperation
        protocol between them.  The clients may be simple clients,
        front-ends, "gateways", or embedded in other information access
        clients, such as Gopher or WWW (World Wide Web) client programs.
        The interoperation protocol will define message types, message
        sequences, and data fields.  An element of this protocol should
        be the use of Universal Record Locators (URLs).

    2.  Promote the development of index-servers.  The index-servers
        should use several different methods both for gathering data for
        their indices, and for searching their indices.

    3.  Support a central management for the X.500 system.  To get the
        best advantage of the effort already invested in the X.500
        directory system it is essential to provide the relatively small
        amount of central management necessary to keep the system
        functioning.

    4.  Support the development of security certificate storage and
        retrieval from the white pages service.  One practical approach
        is initially to focus on getting support from the existing X.500
        directory infrastructure.  This effort should also include
        design and development of the storage and retrieval of security
        certificates for other white pages services, such as Whois++.













Postel & Anderson                                               [Page 3]

RFC 1588                   White Pages Report              February 1994


2. HISTORY

   In February 1989, a meeting on Internet white pages service was
   initiated by the FRICC (Federal Research Internet Coordinating
   Committee) and the ensuing discussions resulted in RFC 1107 [1] that
   offered some technical conclusions.  Widespread deployment was to
   have taken place by mid-1992.

         RFC 1107: K. Sollins, "Plan for Internet Directory Services",
         [1].

   Several other RFCs have been written suggesting deployment strategies
   and plans for an X.500 Directory Service.

   They are:

         RFC 1275: S. Hardcastle-Kille, "Replication Requirements to
         provide an Internet Directory using X.500", [2].

         RFC 1308: C. Weider, J. Reynolds, "Executive Introduction to
         Directory Services Using the X.500 Protocol", [3].

         RFC 1309: C. Weider, J. Reynolds, S. Heker, "Technical Overview
         of Directory Services Using the X.500 Protocol", [4].

         RFC 1430: S. Hardcastle-Kille, E. Huizer, V. Cerf, R. Hobby &
         S. Kent, "A Strategic Plan for Deploying an Internet X.500
         Directory Service", [5].

   Also, a current working draft submitted by A. Jurg of SURFnet
   entitled, "Introduction to White pages services based on X.500",
   describes why we need a global white pages service and why X.500 is
   the answer [6].

   The North America Directory Forum (NADF) also has done some useful
   work setting conventions for commercial providers of X.500 directory
   service.  Their series of memos is relevant to this discussion.  (See
   RFC 1417 for an overview of this note series [7].)  In particular,
   NADF standing document 5 (SD-5) "An X.500 Naming Scheme for National
   DIT Subtrees and its Application for c=CA and c=US" is of interest
   for its model of naming based on civil naming authorities [8].

   Deployment of a X.500 directory service including that under the PSI
   (Performance Systems International) White Pages Pilot Project and the
   PARADISE Project is significant, and continues to grow, albeit at a
   slower rate than the Internet.





Postel & Anderson                                               [Page 4]

RFC 1588                   White Pages Report              February 1994


3. QUESTIONS

   Four questions were posed to the discussion list:

      1) What functions should a white pages directory perform?

      2) What approaches will provide us with a white pages directory?

      3) What are the problems to be overcome?

      4) What should the deployment strategy be?

3.A. WHAT FUNCTIONS SHOULD A WHITE PAGES DIRECTORY PERFORM?

   The basic function of a white pages service is to find people and
   information about people.

   In finding people, the service should work fast when searching for
   people by name, even if the information regarding location or
   organization is vague.  In finding information about people, the
   service should retrieve information associated with people, such as a
   phone number, a postal or email address, or even a certificate for
   security applications (authentication, integrity, and privacy).
   Sometimes additional information associated with people is provided
   by a directory service, such as a list of publications, a description
   of current projects, or a current travel itinerary.

   Back in 1989, RFC 1107 detailed 8 requirements of a white pages
   service: (1) functionality, (2) correctness of information, (3) size,
   (4) usage and query rate, (5) response time, (6) partitioned
   authority, (7) access control, (8) multiple transport protocol
   support; and 4 additional features that would make it more useful:
   (1) descriptive naming that could support a yellow pages service, (2)
   accountability, (3) multiple interfaces, and (4) multiple clients.

   Since the writing of RFC 1107, many additional functions have been
   identified.  A White Pages Functionality List is attached as Appendix
   1.  The problem is harder now, the Internet is much bigger, and there
   are many more options available (Whois++, Netfind, LDAP (Lightweight
   Direct Access Protocol), different versions of X.500 implementations,
   etc.)

   A white pages directory should be flexible, should have low resource
   requirements, and should fit into other systems that may be currently
   in use; it should not cost a lot, so that future transitions are not
   too costly; there should be the ability to migrate to something else,
   if a better solution becomes available; there should be a way to
   share local directory information with the Internet in a seamless



Postel & Anderson                                               [Page 5]

RFC 1588                   White Pages Report              February 1994


   fashion and with little extra effort; the query responses should be
   reliable enough and consistent enough that automated tools could be
   used.

3.B. WHAT APPROACHES WILL PROVIDE US WITH A WHITE PAGES DIRECTORY?

   People have different needs, tastes, etc.  Consequently, a large part
   of the ultimate solution will include bridging among these various
   solutions.  Already we see a Gopher to X.500 gateway, a Whois++ to
   X.500 gateway, and the beginnings of a WWW to X.500 gateway.  Gopher