rfc1309.txt

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

   The functionality built into the X.500(88) standard includes:

   * Advanced searching capabilities.
     The Directory supports arbitrarily complex searches at an
     attribute level. As the object classes a specific entry
     belongs to is maintained in the objectClass attribute, this
     also allows Directory searches for specific types of objects.
     Thus, one could search the c=US subtree for anyone with a last
     name beginning with S, who also has either a fax number in the
     (313) area code or an e-mail address ending in umich.edu.
     This feature of X.500 also helps to provide the basic
     functionality for a Yellow Pages service.




DISI Working Group                                             [Page 11]

RFC 1309              Technical Overview of X.500             March 1992


   * A uniform namespace with local extensibility.
     The Directory provides a uniform namespace, but local
     specialized directories can also be implemented.  Locally
     defined extensions can include new object classes, new
     attributes, and new attribute types.

   * Security issues.
     The X.500 (88) standards define two types of security for
     Directory data: Simple Authentication (which uses passwords),
     and Strong Authentication (which uses cryptographic keys).
     Simple authentication has been widely implemented, strong
     authentication has been less widely implemented.  Each of
     these authentication techniques are invoked when a user or
     process attempts a Directory operation through a DUA.

   In addition to the global benefits of the X.500 standard, there are
   many local benefits. One can use their local DSA for company or
   campus wide directory services; for example, the University of
   Michigan is providing all the campus directory services through
   X.500. The DUAs are available for a wide range of platforms,
   including X-Windows systems and Macintoshes.

3.2.2 Functionality added by QUIPU.

   Functionality beyond the X.500 (88) standard implemented by QUIPU
   includes:

   * Access control lists.
     An access control list is a way to provide security for each
     attribute of an entry.  For example, each attribute in a given
     entry can be permitted for detect, compare, read, and modify
     permissions based on the reader's membership in various groups.
     For example, one can specify that some information in a given
     entry is public, some can be read only by members of the
     organization, and some can only be modified by the owner of
     the entry.

   * Replication.
     Replication provides a method whereby frequently accessed
     information in a DSA other than the local one can be kept by
     the local DSA on a "slave" basis, with updates of the "slave"
     data provided automatically by QUIPU from the "master" data
     residing on the foreign DSA.  This provides alternate access
     points to that data, and can make searches and retrievals
     more rapid as there is much less overhead in the form or
     network transport.





DISI Working Group                                             [Page 12]

RFC 1309              Technical Overview of X.500             March 1992


3.3 Current limitations of the X.500 standard and implementations.

   As flexible and forward looking as X.500 is, it certainly was not
   designed to solve everyone's needs for all time to come. X.500 is not
   a general purpose database, nor is it a Data Base Management System
   (DBMS). X.500 defines no standards for output formats, and it
   certainly doesn't have a report generation capability. The technical
   mechanisms are not yet in place for the Directory to contain
   information about itself, thus new attributes and new attribute types
   are rather slowly distributed (by hand).

   Searches can be slow, for two reasons: a) searches across a widely
   distributed portion of the namespace (c=US, for example) has a delay
   which is partially caused by network transmission times, and can be
   compounded by implementations that cache the partial search returns
   until everyone has reported back, and b) some implementations are
   slow at searching anyway, and this is very sensitive to such things
   as processor speed and available swap space.  Another implementation
   "problem" is a tradeoff with security for the Directory: most
   implementations have an administrative limit on the amount of
   information which can be returned for a specific search.  For
   example, if a search returns 1000 hits, 20 of those might be
   displayed, with the rest lost. Thus a person performing a large
   search might have to perform a number of small searches.  This was
   implemented because an organization might want to make it hard to
   "troll" for the organization's entire database.

   Also, there is at the moment no clear consensus on the ideal shape of
   the DIT, or on the idea structure of the object tree.  This can make
   it hard to add to the current corpus of X.500 work, and the number of
   RFCs on various aspects of the X.500 deployment is growing monthly.

   Despite this, however, X.500 is very good at what it was designed to
   do; i.e., to provide primary directory services and "resource
   location" for a wide band oftypes of information.

3.4 Things to be added in X.500 (92).

   The 1988 version of the X.500 standard proved to be quite sufficient
   to start building a Directory Service. However, many of the new
   functions implemented in QUIPU were necessary if the Directory were
   to function in a reasonable manner. X.500 (92) will include
   formalized and standardized versions of those advances, including

   * A formalized replication procedure.

   * Enhanced searching capacities.




DISI Working Group                                             [Page 13]

RFC 1309              Technical Overview of X.500             March 1992


   * Formalization of access control mechanisms, including access
     control lists.

   Each of these will provide a richer Directory, but you don't have to
   wait for them! You can become part of the Directory today!

4: WHAT X.500 CAN DO FOR YOU TODAY

4.1 Current applications of X.500

   X.500 is filling Directory Services needs in a large number of
   countries.  As a directory to locate people, it is provided in the
   U.S. as the White Pages Pilot Project, run by PSI, and in Europe
   under the PARADISE Project as a series of nation-wide pilots.  It is
   also being used by the FOX Project in the United States to provide
   WHOIS services for people and networks, and to provide directories of
   objects as disparate as NIC Profiles and a pilot K-12 Educators
   directory. It is also being investigated for its ability to provide
   resource location facilities and to provide source location for WAIS
   servers. In fact, in almost every area where one could imagine
   needing a directory service (particularly for distributed directory
   services), X.500 is either providing those services or being expanded
   to provide those services.

   In particular, X.500 was envisioned by its creators as providing
   directory services for electronic mail, specifically for X.400. It is
   being used in this fashion today at the University of Michigan:
   everyone at the University has a unified mail address, e.g.
   [e-mail]. An X.500 server then reroutes that mail to
   the appropriate user's real mail address in a transparent fashion.
   Similarly, Sprint is using X.500 to administrate the address space
   for its internal X.400 mail systems.

   Those of us working on X.500 feel that X.500's strengths lie in
   providing directory services for people and objects, and for
   providing primary resource location for a large number of online
   services. We think that X.500 is a major component (though not the
   only one) of a global Yellow Pages service. We would also like to
   encourage each of you to join your national pilot projects; the more
   coverage we can get, the easier you will be able to find the people
   you need to contact.










DISI Working Group                                             [Page 14]

RFC 1309              Technical Overview of X.500             March 1992


5.  For Further Information

   For further information, the authors recommend the following
   documents:

      Weider, C., and J. Reynolds, "Executive Introduction to Directory
      Services Using the X.500 Protocol", FYI 13, RFC 1308, ANS, ISI,
      March 1992.

      Lang, R., and R. Wright, Editors, "A Catalog of Available X.500
      Implementations", FYI 11, RFC 1292, SRI International, Lawrence
      Berkeley Laboratory, January 1992.

      Barker, P., and S. Hardcastle-Kille, "The COSINE and Internet
      X.500 Schema", RFC 1274, University College London, November 1991.

      Hardcastle-Kille, S., "Replication Requirements to provide an
      Internet Directory using X.500", RFC 1275, University College
      London, November, 1991.

      Hardcastle-Kille, S., "Replication and Distributed Operations
      extensions to provide an Internet Directory using X.500", RFC
      1276, University College London, November 1991.

      Hardcastle-Kille, S., "Encoding Network Addresses to support
      operation over non-OSI lower layers", RFC 1277, University College
      London, November 1991.

      Hardcastle-Kille, S., " A string encoding of Presentation
      Address", RFC 1278, University College London, November 1991.

      Hardcastle-Kille, S., "X.500 and Domains", RFC 1279, University
      College London, November 1991.

6.  Security Considerations

      Security issues are discussed in section 3.














DISI Working Group                                             [Page 15]

RFC 1309              Technical Overview of X.500             March 1992


7.  Authors' Addresses

      Chris Weider
      Advanced Network and Services, Inc.
      2901 Hubbard G-1
      Ann Arbor, MI 48105-2437

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


      Joyce K. Reynolds
      Information Sciences Institute
      University of Southern California
      4676 Admirality Way
      Marina del Rey, CA 90292

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


      Sergio Heker
      JvNCnet
      Princeton University
      6 von Neumann Hall
      Princeton, NJ 08544

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






















DISI Working Group                                             [Page 16]