rfc1107.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

         that it has become stable.  The implementation is UNIX-based
         only and uses TCP.

      X.500

         X.500 is the CCITT recommendation (also ISO/IEC/DIS 9594) [4]
         for a directory service.  Because it is a CCITT recommendation,
         it evolves in four year study periods, one of which has
         recently come to a close.  Thus, X.500 has a stable definition
         for the next four years.

         In X.500, the set of all objects forms a single hierarchy, with
         each object being named relative to its parent and a single
         root as the topmost parent.  An object consists of a set of
         attributes.  Searching can be done by use of a logical
         combination of attribute values, known as a filter.  A subset
         of these attributes comprise an object's distinguished name
         relative to its parent.  The hierarchy as described in the
         CCITT recommendation is geographic at its top level and
         organizational within that.  Alternatives can also be defined,
         although they are not part of the CCITT or ISO documents.  In
         addition, there is no proposed mechanisms for distributing
         information about other attribute types or object classes.  As
         with the other services, X.500 is a distributed service.  It



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


         specifies cooperating servers or Directory Server Agents (DSAs)
         under local control and management each of which knows about
         one or more parts of the hierarchy.  The clients are known as
         Directory User Agents (DUAs).  It is defined to run on top of
         the OSI protocol stack.  The demonstrations of X.500 in the
         context of Internet run on top of the ISODE package, which
         provides OSI transport on top of TCP.

         X.500 is incomplete in that there are a number of identifiable
         areas in which the standard says nothing, but that need to be
         specified for a successful implementation.  Some examples of
         these are: access control (although authentication is
         supported), replication, caching, the database itself (the
         shape of the hierarchy), tools to limit the scope and cost of
         searching, and database management tools.

         There are currently a small number of implementations of X.500
         in progress at such locations as University College London (the
         Quipu project, on UNIX using ISODE), the University of British
         Columbia (UNIX based using their own full OSI suite), MIT
         (experimental, Symbolics Lisp Machine based, Lisp using TCP),
         The Wollongong Group (offshoot of Quipu), The Retix
         Corporation, NIST, and at least several underway in Italy and
         Japan.  There are probably others and a number of other
         American corporations have discussed building their own.  Each
         of these must make its own decision in the areas in which X.500
         is silent.  Quipu is probably the most complete implementation
         of X.500 to date.  The pilot version has about 20 DUAs in seven
         countries with an estimated 20,000 entries total.

4. Proposed Approach

   The conclusion of this report is that some form of X.500 is the most
   likely candidate.  The reasons for this decision are that it has a
   rich semantics and will become the international de facto standard.
   There are, however, serious problems with its incompleteness and with
   its strict hierarchy.  Therefore, in order to explore these and
   become convinced of its viability, the attendees at the meeting
   agreed on field trials, as a first stage.  Initially, this would
   include experiments with at least one X.500 implementation (Quipu),
   Profile to explore a non-hierarchical structure and richer
   descriptive naming, and DNANS in order to explore some of the
   incomplete aspects of X.500 for which DNANS has architected
   solutions.

   A three-stage plan, with all three stages beginning coincidentally
   and as soon as possible, would provide such a service within the NRN.
   The first stage should be complete in a year, the second in two, and



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


   the third in three.  Stage 1 would be field trials of three
   approaches to naming with an emphasis on distinguishing between the
   specification and a particular implementation of X.500, as well.
   Stage 2 would be a more complete implementation of a white pages
   service base on the conclusions from Stage 1.  Stage 3 would be
   widespread deployment of the implementation developed in Stage 2.
   The planning for Stage 3 is not outlined here in detail, because that
   plan would be part of the proposed work to be done.  If the field
   trials were to lead to the conclusion that none of the services is
   adequate, the plan for the remainder of the work would need to be
   rescheduled.

   If the Internet community is to adopt X.500 (or any other standard),
   it is necessary to make a number of design and management decisions,
   above and beyond the implementation decisions for the DSA.  Since
   there are a number of such decisions to be resolved, and some of
   these are significant, the group recommended that this planning and
   management function should be recognized as a distinct activity.

4.1. Stage 1: The Field Test

   It was agreed that field trials would be a valuable form in which to
   explore the issues of building a white pages service for two reasons.
   First, the software is still in early stages of development or
   deployment.  Some of it is production code, but still first release;
   the rest is part of research projects.  Second, it is important to
   learn from experience with a limited and sympathetic community.  The
   suggested community was the computer science community, in
   particular, computer science departments.  That will not be the case
   completely, since the computer science community in general does not
   use DECnet.  Therefore, for experiments with the DNANS, the NASA/DOE
   community was recommended.  They will be using DNANS in any case, as
   they move to DECnet Phase V.

   The twofold purpose of the field trials is to explore differing
   directory service architectures and to refine the study of X.500
   specifically, to distinguish architectural aspects of it from
   features of a particular implementation of X.500.  Initially, the
   trials would include the Quipu implementation of X.500, Profile, and
   the DNANS.  A second implementation of X.500 should be identified and
   included as soon as possible.  Part of the emphasis of the field
   trials would be on gathering and maintenance of naming information.
   To ease this, a single common file format for storage of and access
   to the naming information and use of a single set of data management
   tools was recommended, although no particular set was identified.
   The various directory services would need to be retrofitted to this
   file format.  Such consistency in file format would mean that the
   services could all be co-resident, sharing files, thus permitting



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


   single locations to participate in several parts of the field trials.
   This, in turn, would allow for direct comparisons.

   There are a number of issues, which are not addressed in X.500, that
   would need to be resolved for a large scale deployment such as a
   white pages for the NRN.  In particular, these are: clients of the
   service; data collection and maintenance; distribution, replication
   and caching of information; access control, accountability, and
   information integrity; and support by non-OSI protocols.  Each of the
   name services included in the field trials would include decisions in
   these areas, albeit different ones.  The field trials will allow for
   evaluation of these different mechanisms.

   There are two other major issues that must also be addressed:
   functionality and size.  Functionality encompasses both the first
   point of the nature of the interfaces to the service as well as the
   structure of the namespace (e.g., hierarchy).  A discussion of size
   must include not only the number of entries handled by the service as
   a whole, but how those entries are distributed and the query and
   update patterns.

   In general, all of these issues are tightly coupled, but are
   separated here for the purposes of understanding the field trials and
   its potential effectiveness.  They would also be the issues that
   would be the basis for the work done in Stage 2 of the project.

      - Functionality:

         X.500 and DNANS make strong statements about the organization
         of the namespace.  In both cases, it is a single, absolute
         hierarchy with soft links or aliases and attribute-based naming
         useful both in searches of subtrees of the hierarchy and for
         storing information about the objects in the hierarchy.  The
         searches are based on logical combinations of attribute values.
         Quipu implements the naming structure and search functionality
         as specified in X.500.  In contrast, Profile, provides a more
         general facility that supports any form of relative names, not
         just hierarchical, and a small programming language to express
         the functions for searching.  By including Profile in the field
         trials, these more general facilities can be tested.

         X.500 specifies that the service is separated into two parts
         for implementation of the service, known as the Directory
         Service Agent (DSA), and the client, known as the Directory
         User Agent (DUA).  DUAs can be implemented independently of the
         implementation of the white pages service.  Quipu, Profile, and
         DNANS have taken different approaches to the presentation model
         for DUAs, so the three implementations will allow for



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


         additional experience.

      - Size:

         As discussed earlier, a white pages service must be prepared to
         handle a minimum of 10**7 entries, although they may be
         distributed, and a query rate of hundreds per second.  It must
         also be prepared to handle much higher peak rates.  If the
         address lookup that is presently provided by the DNS is also
         supported by the white pages service, the query rate will be
         much higher.  The designers of the field trials must determine
         whether or not such usage will be part of the final service and
         therefore must be examined in the field trials.  If so, caching
         may be part of the solution.  In addition, the response time
         for DUAs must be reasonable for a human sitting at a console.
         Furthermore, modifications to the data should occur in
         reasonably short periods of time, although this could be
         measured in hours.

         The field trials must allow for experimentation under such
         stressful conditions.  The environment for testing must have
         both large and small nodes, as well as both heavy and light
         load querying and situations in which reorganization can be
         tested.  Such reorganization may be a simple as moving one
         piece of the hierarchy to another point and handling naming
         conflicts in the new environment.  X.500 does not address this
         issue, but it will be needed by the NRN.

      - Distribution, replication, and caching:

         These are areas in which X.500 has very little to say, but a
         great deal of work has been done in other distributed, network
         naming services, in particular both the DNS and DNANS.  There
         seems to be general agreement that distribution of naming
         services should be done on the basis of nodes in the naming
         structure, which also provide the basis for administrative
         partitioning.  All the naming services described here support
         distribution, partitioning of the information for placement on
         cooperating servers.  Neither X.500 (and therefore Quipu) nor
         Profile is prepared to redistribute portions of the namespace,
         for reallocation of administrative responsibilities or load
         balancing, although this should be possible and DNANS is
         prepared to do so.  Replication is necessary for accessibility
         in a large-scale or global namespace, although again X.500 does
         not address this issue.  Quipu has taken a stand on this, by
         defining master and slave copies of the data; it is similar to,
         but not the same as, the approach taken in the DNS.  Caching is
         barely touched on in X.500 and not at all in Profile, but our



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


         experience with the DNS indicates that caching is critical to
         effective operation of a distributed name service.  The DNANS
         has an architected solution based on objects in the namespace
         as the unit of distribution and replication.  Again, the DNANS
         solution should be explored in the field test environment.

      - Access control, accountability, and integrity:

         Access control and accountability require some degree of
         authentication.  X.500 supports authentication based on using
         an RSA public key algorithm, but does not address issues of