rfc1107.txt

RFC 的详细文档！

Network Working Group                                         K. Sollins
Request for Comments:  1107       M.I.T. Laboratory for Computer Science
                                                               July 1989


                 A Plan for Internet Directory Services


                           Table of Contents

   1. Introduction                                                  1
        1.1. The Issues                                             1
        1.2. Project Summary                                        3
   2. Goals and Requirements for a White Pages Service              6
   3. Pre-existing Services                                         9
   4. Proposed Approach                                            11
        4.1. Stage 1: The Field Test                               12
        4.2. Stage 2: Implementation                               17
        4.3. Stage 3: Deployment                                   17
   5. Conclusion                                                   18

Status of this Memo

   This memo proposes a program to develop a directory service for the
   Internet.  It reports the results of a meeting held in February 1989,
   which was convened to review requirements and options for such a
   service.  This proposal is offered for comment, and does not
   represent a committed research activity of the Internet community.
   Activity in this area is anticipated, and comments should be provided
   promptly.  Distribution of this memo is unlimited.

1. Introduction

1.1. The Issues

   As part of the planned growth of the Internet (in particular, in
   support of the full science research community in the U.S.), an
   increasing need is anticipated for various sorts of directory
   services.  The increase in the size of the community served by the
   Internet and the burgeoning demands for electronic mail lead to the
   need for a service to find people's computer mailboxes and other
   relevant facts, a so-called "White Pages" service.  At the user level
   to date, there have been no such national or international white
   pages services in general use.  As part of building the National
   Research Network (NRN), it is important that such a service exist,
   not only within the NRN community, but also crossing the boundaries
   from the NRN to the more global network community.  This will enhance
   communication not only among computer scientists, but also among



Sollins                                                         [Page 1]

RFC 1107         A Plan for Internet Directory Services        July 1989


   scientists and engineers in other fields as well.  Also important and
   related is a so-called "Yellow Pages" service, which permits the
   location of Internet resources based on their attributes.

   A "White Pages" service is one in which one can look up people in
   order to learn information about them for finding them.  In its
   simplest form, a white pages service provides what the white pages
   telephone book provides.  Based on a name, one can find an address
   and a telephone number.  In a network environment, there may be many
   other kinds of location information, such as electronic mailbox,
   electronic calendar, or file server, where one might leave a file for
   the recipient.  In addition, the electronic white pages may support a
   much more sophisticated set of mechanisms for lookup.  One might
   match on a more complex set of attributes than first and last name.
   In addition, the searching might span more than one local white pages
   service.  There are a number of naming and directory service
   specifications and implementations in the field.  They have differing
   functionality and mechanisms to address that functionality.

   Within the the world of networking today, there are a number of
   partial solutions to the directory service problem.  Examples of
   these are the Internet Domain Naming Service (DNS), Clearinghouse,
   DECnet Network Architecture Naming Service (DNANS), Profile, and
   X.500.  The Domain Naming Service provides a directory service most
   commonly used for host naming and mail delivery.  Clearinghouse and
   DNANS are respectively the Xerox and DEC corporate naming services,
   originally for mail delivery, although having other uses as well, in
   both cases.  Profile is part of the work of Larry Peterson to explore
   descriptive naming in a non-hierarchical structure.

   There is a CCITT recommendation X.500 (ISO DIS 9594), which defines a
   general directory service.  One of its primary goals is the naming
   service needed for message handling (X.400).  While X.500 is still
   developing, and would need further evolution to cover all the
   requirements of a service for the Internet, it will have an important
   impact on the Internet community.  It will form the basis of
   commercial products, and it will almost certainly be the directory
   service of many parts of the network world, which implies a need to
   interoperate at a minimum.  There is some concern that despite the
   fact that X.500 is a recognized standard, there are a number of gaps
   and limitations of the approach, that in turn will cause it to be
   inadequate for the needs of the NRN.

   In this context, a meeting was held to review current requirements
   and solutions for directory services.  This RFC reports the results
   of that meeting, including the possibilities for a program of work in
   this area.




Sollins                                                         [Page 2]

RFC 1107         A Plan for Internet Directory Services        July 1989


   For two days, a group representing academic, commercial, and
   government interests in directory services discussed both alternative
   candidates for a white pages service and the issues in building any
   such service.  The meeting was kept small by inviting only a small
   number of representatives of each perspective.  By the conclusion of
   the second day, a consensus was reached on how one could achieve a
   white pages service in three years.  This is summarized in the next
   section.

1.2. Project Summary

   The consensus of the meeting can be summarized in the following five
   points:

      1. The standards and implementations are close enough to being
         complete that it is reasonable to undertake provision of an NRN
         "White Pages" service.

      2. Although we are close, an effort is needed to experiment with
         different levels of service, to flesh out the standards, and to
         develop code.

      3. An initial evaluation experiment is needed before making final
         detailed plans for a production version of the service.

      4. With strong funding and encouragement, a production service is
         possible in three years.

      5. It is important to act now to provide a coherent solution.
         This means both having an impact on the evolving standards
         and providing a unified, wide-spread solution before a plethora
         of differing solutions appear.

   Although it has clearcut drawbacks, X.500 was identified as the most
   likely candidate directory service.  The reasons for this are that it
   has rich semantics and is becoming the accepted international
   standard.  However, there are problems with its incompleteness and
   with its strict hierarchy.  Therefore, in order to explore these and
   become convinced of its viability, the consensus at the meeting was
   to propose field trials, as the project's first stage.  The field
   trials would be limited in the user community, perhaps restricted to
   computer science departments because of their familiarity with the
   problems, and would be based on experimental or new software.  They
   would include experiments with at least an X.500 implementation,
   Profile, and DNANS.  Each of these services has strong points that
   must be considered as part of the evaluation.  They are:





Sollins                                                         [Page 3]

RFC 1107         A Plan for Internet Directory Services        July 1989


      X.500:  International standard, hierarchy, search rules and
              filters for searching attributed based names.

      Profile:  Descriptive naming with a richer semantics for
                describing search criteria, an arbitrary network
                of servers.

      DNANS:  Access control, replication, caching, hierarchy.

   In summary, the plan would fall into three stages as follows:

      - Stage 1:  Field Trials.

         There are two aspects to the field trials.  The first is to
         explore several different architectures for a white pages
         service.  To this end, implementations of X.500, Profile, and
         DNANS should be included.  The second aspect of the field
         trials is to distinguish issues inherent in the X.500
         specification from artifacts of a particular implementation of
         it.  Therefore, if possible, two implementations of X.500
         should be included.  Only one such implementation, Quipu, was
         identified as developed enough to be included in a field trial
         at present, but others are under way, and will follow.  This
         stage must also include a careful and objective review of the
         field trials.

      - Stage 2:  Implementation.

         This stage will include work on both the service and user
         interfaces.  The field trials could result in one of a variety
         of conclusions about the service.  These may range from
         concluding that one or another of the services suits the needs
         of the NRN to proposing a compromise position based on a
         combination of shortcomings of any one service and the features
         of others to address those shortcomings.  Because X.500 will
         become the standard in other domains, an interface to X.500
         will be necessary.  Since all of these implementations are
         still under development, in order to provide production quality
         code, more implementation work will be needed.

         Although some work will have been done on the user interfaces,
         much more will be needed in this stage to provide a variety of
         interfaces.  Much emphasis should be placed on this in Stage 2.

      - Stage 3:  Deployment.

         Deployment of the full white pages service requires information
         gathering in order to fill the directory service, placement of



Sollins                                                         [Page 4]

RFC 1107         A Plan for Internet Directory Services        July 1989


         servers, distribution of and training for use of client code,
         placement and management of services, and delegation of
         authority within the service for authority over the contents.
         Data collection and some delegation of authority as well as
         training for users of the client code would begin during the
         field trial.  This stage would begin concurrently with the
         other two.  During the second year, detailed planning for
         deployment must take place.  This stage would conclude in three
         years, at which time widespread deployment would have occurred.

   In order to undertake this three stage program effectively, the group
   identified the following major projects:

      - Further implementation of code for the field trials.

         In each case (e.g., Quipu, Profile, and DNANS), programs exist,
         although modifications are likely to be necessary.  For
         example, each will need to be modified to utilize the common
         file format into which the input data about users will be
         gathered.

      - Design, development and evaluation of user interfaces.

      - Design and development of data gathering and management tools.

      - Oversight and evaluation of the field trials.

         Careful thought and planning must go into the field trials, to
         guarantee that we learn what is needed to make an evaluation
         and to plan for the white pages service.  The evaluation must
         also produce a document that is both a general specification
         (assuming no one alternative is chosen wholesale) and profiling
         information, in order for later interoperability and
         conformance testing.

      - Detailed planning and later management of deployment.