rfc1330.txt

RFC 的详细文档！

   PRMD peering, bidirectional X.400-SMTP relaying and



ESCC X.500/X.400 Task Force                                     [Page 5]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   private/commercial X.400 routing are discussed.

   Finally, the issues in name registration with ANSI (American National
   Standards Institute), GSA (General Services Administration) and the
   U.S. Department of Commerce, Patent and Trademark Office (PTO) are
   discussed.

2.  X.500 - OSI Directory Services

2.1.  Brief Tutorial

   X.500 is a CCITT/ISO standard which defines a global solution for the
   distribution and retrieval of information (directory service).  The
   X.500 standard includes the following characteristics:  decentralized
   management, powerful searching capabilities, a single global
   namespace, and a structured framework for the storage of information.
   The 1988 version of the X.500 standard specifies four models to
   define the Directory Service: the Information Model, the Functional
   Model, the Organizational Model and the Security Model.  As is the
   nature of International standards, work continues on the 1992 X.500
   standard agreements.

   The Information Model specifies how information is defined in the
   directory.  The Directory holds information objects, which contain
   information about "interesting" objects in the real-world.  These
   objects are modeled as entries in an information base, the Directory
   Information Base (DIB).  Each entry contains information about one
   object:  ie, a person, a network, or an organization.  An entry is
   constructed from a set of attributes each of which holds a single
   piece of information about the object.  For example, to build an
   entry for a person the attributes might include "surname",
   "telephoneNumber", "postalAddress", "rfc822Mailbox" (SMTP mail
   address), "mhsORAddresses" (X.400 mail address) and
   "facsimileTelephoneNumber".  Each attribute has an attribute syntax
   which describes the data that the attribute contains, for example, an
   alphanumeric string or photo data.  The OSI Directory is extensible
   in that it defines several common types of objects and attributes and
   allows the definition of new ones as new applications are developed
   that make use of the Directory.  Directory entries are arranged in a
   hierarchical structure, the Directory Information Tree (DIT).  It is
   this structure which is used to uniquely name entries.  The name of
   an entry is its Distinguished Name (DN).  It is formed by taking the
   DN of the parent's entry, and adding the the Relative Distinguished
   Name (RDN) of the entry.  Along the path, the RDNs are collected,
   each naming an arc in the path.  Therefore, a DN for an entry is
   built by tracing the path from the root of the DIT to the entry.

   The Functional Model defines how the information is stored in the



ESCC X.500/X.400 Task Force                                     [Page 6]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   directory, and how users access the information.  There are two
   components of this model:  the Directory User Agent (DUA), an
   application-process which interacts with the Directory on behalf of
   the user, and the Directory System Agent (DSA), which holds a
   particular subset of the Directory Information Tree and provides an
   access point to the Directory for a DUA.

   The Organizational Model of the OSI Directory describes the service
   in terms of the policy defined between entities and the information
   they hold.  The model defines how portions of the DIT map onto DSAs.
   A Directory Management Domain (DMD) consists of one or more DSAs,
   which collectively hold and manage a portion of the DIT.

   The Security Model defines two types of security for Directory data:
   Simple Authentication (using passwords) and Strong Authentication
   (using cryptographic keys).  Authentication techniques are invoked
   when a user or process attempts a Directory operation through a DUA.

2.2.  Participation in the PSI White Pages Pilot Project

   The PSI White Pages Pilot Project is currently the most well-
   established X.500 pilot project within the United States.  For the
   country=US portion of the DIT, PSI currently has over 80 organization
   names registered.  Of these, several are ESnet-related.

   The PSI White Pages Pilot Project is also connected to the Pilot
   International Directory Service, PARADISE.  This pilot project
   interconnects X.500 Directory Services between Australia, Austria,
   Belgium, Canada, Denmark, Finland, France, Germany, Greece, Iceland,
   Ireland, Israel, Italy, Japan, Luxembourg, Netherlands, New Zealand,
   Norway, Portugal, Spain, Sweden, Switzerland, United Kingdom and
   Yugoslavia.  The combined totals for all of these countries
   (including the United States) as of December 1991 are:

                       DSAs:                     301
                       Organizations:          2,132
                       White Pages Entries:  581,104

   Considering the large degree of national, and international,
   connectivity within the PSI White Pages Pilot Project, it is
   recommended that directly connected ESnet backbone sites join this
   pilot project.

2.3.  Recommended X.500 Implementation

   Interoperability testing has not been performed on most X.500
   implementations.  Further, some X.500 functions are not mature
   standards and are often added by implementors as noninteroperable



ESCC X.500/X.400 Task Force                                     [Page 7]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   extensions.

   To ensure interoperability for the entire ESnet community, the
   University College London's publicly available X.500 implementation
   (QUIPU) is recommended.  This product is known to run on several
   UNIX-derivative platforms, operates over CLNS and RFC-1006 (with
   RFC-1006 being the currently recommended stack), and is currently in
   wide-spread use around the United States and Europe, including
   several ESnet backbone sites.

   Appendix C contains information on how to obtain QUIPU.

   A later phase deployment of X.500 services within the ESnet community
   will recommend products (either commercial or public domain) which
   pass conformance and interoperability tests.

2.4.  Naming Structure

   As participants in the PSI White Pages Pilot Project, ESnet backbone
   sites will align with the naming structure used by the Pilot.  This
   structure is based upon a naming scheme for the US portion of the DIT
   developed by the North American Directory Forum (NADF) and documented
   in RFC-1255.  Using this scheme, an organization with national
   standing would be listed directly under the US node in the global
   DIT.  Organizations chartered by the U.S. Congress as well as
   organizations who have alphanumeric nameforms registered with ANSI
   are said to have national standing.  Therefore, a backbone site which
   is a national laboratory would be listed under country=US:

              @c=US@o=Lawrence Livermore National Laboratory

   As would a site with an ANSI-registered organization name:

           @c=US@o=National Energy Research Supercomputer Center

   A university would be listed below the state in which it is located:

                @c=US@st=Florida@o=Florida State University

   And a commercial entity would be listed under the city or state in
   which it is doing business, or "Doing Business As", depending upon
   where its DBA is registered:

                   @c=US@st=California@o=General Atomics
                                   (or)
             @c=US@st=California@l=San Diego@o=General Atomics

   A list of the current ESnet backbone sites, and their locations, is



ESCC X.500/X.400 Task Force                                     [Page 8]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   provided in Appendix E.

   Directly connected ESnet backbone sites will be responsible for
   administering objects which reside below their respective portions of
   the DIT.  Essentially, they must provide their own "Name Registration
   Authority".  Although this may appear as an arduous task, it is
   nothing more than the establishment of a procedure for naming, which
   ensures that duplicate entries do not occur at the same level within
   a sub-tree of the DIT.  For example, the Name Registration Authority
   for MIT could create an Organizational Unit named "Computer Science".
   This would appear in the DIT as:

             @c=US@st=Massachusetts@o=MIT@ou=Computer Science

   Similarly, all other names created under the
   "@c=US@st=Massachusetts@o=MIT" portion of the DIT would be
   administered by the same MIT Name Registration Authority.  This
   ensures that every Organizational Unit under
   "@c=US@st=Massachusetts@o=MIT" is unique.  By default, each ESnet
   Site Coordinator is assumed to be the Name Registration Official for
   their respective site.  If an ESnet Site Coordinator does not wish to
   act in this capacity, they may designate another individual, at their
   site, as the Name Registration Official.

2.4.1.  Implications of the Adoption of RFC-1255 by PSI

   The North American Directory Forum (NADF) is comprised of commercial
   vendors positioning themselves to offer commercial X.500 Directory
   Services.  The NADF has produced several documents since its
   formation.  The ones of notable interest are those which define the
   structure and naming rules for the commercially operated DIT under
   country=US.  Specifically, for an Organization to exist directly
   under c=US, it must be an organization with national-standing.  From
   pages 12-13 of RFC-1255, national-standing is defined in the
   following way:

      "An organization is said to have national-standing if it is
      chartered (created and named) by the U.S. Congress.  An example
      of such an organization might be a national laboratory.  There
      is no other entity which is empowered by government to confer
      national-standing on organizations.  However, ANSI maintains an
      alphanumeric nameform registration of organizations, and this
      will be used as the public directory service basis for
      conferring national-standing on private organizations."

   Thus, it appears that National Laboratories (e.g. LBL, LLNL) are
   considered organizations with national-standing.  However, those
   ESnet backbone sites which are not National Laboratories may wish to



ESCC X.500/X.400 Task Force                                     [Page 9]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   register with ANSI to have their organization list directly under
   c=US, but only if this is what they desire.  It is important to note
   that NADF is not a registration authority, but a group of service
   providers defining a set of rules for information sharing and mutual
   interoperability in a commercial environment.

   For further information on registering with ANSI, GSA or the U.S.
   Patent and Trademark office, refer to Section 4 of this document.
   For more information on PSI, refer to Appendix A.

2.4.2.  Universities and Commercial Entities

   Several of the ESnet backbone sites are not National Laboratories
   (e.g. CIT, FSU, GA, ISU, MIT, NYU, UCLA and UTA).  Typically, at
   these sites, a small collection of researchers are involved in
   performing DOE/OER funded research.  Thus, this set of researchers at
   a given site may not adequately represent the total X.500 community
   at their facility. Additionally, ESnet Site Coordinators at these
   facilities may not be authorized to act as the Name Registration
   Official for their site.  So the question is, how do these sites
   participate in the recommended Phase I deployment of ESnet X.500
   services.  There are two possible solutions for this dilemma:

   1.  If the site is not currently operating an X.500 DSA, the ESnet
       Site Coordinator may be able to establish and administer a
       DSA to master the DOE/OER portion of the site's local DIT,
       e.g. "@c=US@st=<st>@o=<site>@ou=Physics".  Before attempting
       this action, it would be prudent for the Site Coordinator to
       notify or seek approval from some responsible entity.  At such
       time that the site wishes to manage its own organization
       within the X.500 DIT, the ESnet Site Coordinator would have to
       make arrangements to put option 2 into effect.

   2.  If the site is currently operating an X.500 DSA, the ESnet
       Site Coordinator may be able to work out an agreement with the
       current DSA administrator to administer a portion of the
       site's local DIT which would represent the DOE/OER community
       at that site.  For example, if the site were already
       administering the organization "@c=US@st=
       Massachusetts@o=Massachusetts Institute of Technology", the
       ESnet Site Coordinator might then be able to administer the
       organizational unit "@c=US@st=Massachusetts@o=Massachusetts
       Institute of Technology@ ou=Physics".