rfc1330.txt

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

   o  FRED - A User Agent which has been optimized for "white pages"
      types of queries.  The FRED program is meant to be similar to
      the WHOIS network service.  FRED supports reading, searching,
      and modifying information in the X.500 Directory.

   o  POD - An X-windows based User Agent intended for novice users.
      POD relies heavily on the concept of the user "navigating"
      around the DIT.  Pod supports reading and searching.  There are
      no facilities to add entries or to modify the RDNs of entries,
      though most other entry modifications are allowed.

2.6.5.  Directory Service from PCs and MACs

   Smaller workstations and personal computers lack the computing power
   or necessary software to implement a full OSI protocol stack.  As a
   consequence, several "light-weight" protocols have been developed
   whereby the DAP runs on a capable workstation and exports a simpler
   interface to other end-systems.  One such "light weight" protocol,
   the Directory Assistance Service (DAS), is incorporated in the PSI
   Pilot Project software.  Another "light weight" protocol, DIXIE, was
   developed at the University of Michigan.  Publicly available User
   Agents for both the MAC and PC have been developed using the DA-
   service and the DIXIE protocol.  So long as you have the Pilot
   Project software running on one host, you can provide these User
   Agents on many end-systems without having to install the Pilot
   software on all those end-systems.

   For further information about available Directory User Agents, see
   RFC-1292, "Catalog of Available X.500 Implementations".

2.7.  Services Provided by ESnet

   Currently, there are several ESnet backbone sites which are operating
   their own DSAs within the PSI White Pages Pilot Project.  It is
   anticipated that directly connected ESnet backbone sites will
   eventually install and operate their own X.500 DSAs.  In the interim,



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


   ESnet will provide complete support for ESnet backbone sites which
   presently do not have the time, expertise or equipment to establish
   X.500 services.  The mechanism for doing this is described in Section
   2.7.5 below.  Additionally, ESnet will provide a variety of services
   in support of the entire X.500 community.  These are also described
   in the following sections.

2.7.1.  X.500 Operations Mailing List

   ESnet maintains a mailing list for the discussion of relevant X.500
   topics. This mailing list provides a means for sharing information,
   experiences, and expertise about X.500 in the ESnet community.  New
   sites joining the ESnet X.500 community will be announced on the
   mailing list.  New DSA administrators will be able to solicit help
   from more experienced administrators.  When a site brings up a new
   X.500 DSA, the DSA manager should notify the ESnet DSA manager so as
   to ensure they are promptly added to the mailing list.

      General discussion:  [e-mail]
      To subscribe:        [e-mail]

2.7.2.  Accessing the X.500 Directory

   ESnet has made the X.500 service openly available to the entire ESnet
   community via each of the access methods described in Section 2.6
   above.  Host WP.ES.NET provides TELNET access, FINGER and WHOIS
   emulations, querying via electronic mail, as well as remote access
   via light-weight protocols.  By making these services widely
   available, we hope to acquaint more users with the features and
   capabilities of X.500.

   To try out some of the X.500 User Agents, simply TELNET to WP.ES.NET
   and login as user "fred"; no password is required.  You have the
   choice of running the Fred or Pod User Agents.  Fred provides a
   command line interface while Pod provides an X-windows based
   interface.  You can browse through the global X.500 DIT, search for
   persons in various organizations, and even modify your own entry if
   you have one.

   Host WP.ES.NET also provides access to the X.500 Directory via
   emulations of the FINGER and WHOIS utilities.  These interfaces
   support a user-friendly-naming (UFN) scheme that simplifies the
   syntax necessary to search for persons in other organizations.  The
   following WHOIS command lines illustrate searching for persons at
   various ESnet sites, utilizing the UFN syntax (similar FINGER command
   lines could also be constructed):





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


      whois -h wp.es.net leighton,nersc
      whois -h wp.es.net servey,doe
      whois -h wp.es.net logg,slac
      whois -h wp.es.net "russ wright",lbl

   For further information about User Friendly Naming, see Steve
   Hardcastle-Kille's working document titled, "Using the OSI Directory
   to Achieve User Friendly Naming".

2.7.3.  Backbone Site Aliases

   As ESnet backbone sites join the X.500 pilot, their organizations'
   entries will be placed in various parts of the DIT.  For example,
   National Laboratories will be placed directly under the c=US portion
   of the DIT, while universities and commercial entities will most
   likely be placed under localities, such as states or cities.

   In order to facilitate searching for the ESnet community as a whole,
   ESnet backbone sites will also be listed as organizational units
   under the node "@c=US@o=Energy Sciences Network".  These entries will
   actually be aliases which point to the site's "real" organizational
   entry.  Therefore, ESnet backbone sites will be listed in two
   different places in the DIT and one could search for them in either
   location.

2.7.4.  Multiprotocol Stack Support

   OSI applications currently run over many different transport/network
   protocols, a factor which hinders communication between OSI end
   nodes.  In order to facilitate communication, the ISODE may be
   configured at compile time to support any combination of the
   following stacks:

      RFC-1006 over TCP/IP
      TP0      over X.25
      TP0      over X.25 (84)
      TP0      over the TP0-bridge
      TP4      over CLNP

   Within the ESnet community, the stacks of interest are RFC-1006 over
   TCP/IP, TP4 over CLNP, and TP0 over X.25.  If a backbone site's DSA
   is not running over all three of these stacks, it may eventually
   receive referrals to a DSA that it can not connect to directly, so
   the operation can not proceed.  Since the ESnet DSAs will be
   configured to operate over all of the "stacks of interest," they can
   serve as relay DSAs between site DSAs that do not have direct
   connectivity.  The site's DSA manager will need to contact the ESnet
   DSA manager to arrange for this relaying to occur.  Backbone sites



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


   will be encouraged to eventually provide as many of the three stacks
   of interest as possible.

2.7.5.  Managing a Site's X.500 Information

   For sites which do not initially wish to operate their own DSA,
   ESnet's DSA will master their site's portion of the DIT, enabling the
   site to join the PSI Pilot Project and the ESnet X.500 community.  In
   order to accomplish this, the site must provide the ESnet DSA manager
   with information about the people to be included in the X.500
   Directory.  This information can usually be obtained from your Site's
   Personnel Database.

   ESnet will only maintain a limited amount of information on behalf of
   each person to be represented in the Directory.  The attribute types
   listed in the table in Section 2.5 show the maximum amount of
   information which the ESnet DSA will support for a person's entry in
   the Directory. This set of attribute types is a small subset of the
   attribute types offered by the PSI Pilot Project software.
   Therefore, if a site wishes to include additional attribute types,
   they should consider installing and operating their own DSA.

   The format of the information to be provided to the ESnet DSA manager
   is as follows:  the data should be contained in a flat, ASCII text
   file, one record (line) per person, with a specified delimiter
   separating the fields of the record.  More detailed information and a
   sample of a site-supplied data file can be found in Appendix D.

2.7.5.1.  Open Availability of Site Information

   Although the PSI Pilot Project allows you to control who may access
   Directory objects and their attributes, any information you provide
   about persons at your site to be stored in the ESnet DSA will be
   considered world readable.  This policy is necessary in order to
   minimize the administrative cost of managing potentially many
   organizational objects within the ESnet DSA.  If your site decides
   that it does not wish to have certain information about its employees
   publicly known (e.g. work telephone number) then you should not
   provide this information to the ESnet DSA manager or you should
   consider installing and administering your own DSA.

2.7.5.2.  Access Methods for Local Users

   Backbone sites which choose the option of having the ESnet DSA master
   their organization's X.500 information should make the availability
   of the X.500 service known to their local users.  All of the methods
   described in Section 2.7.2 are available for use, but none of these
   methods will assume the query is relative to the local site.



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


   To facilitate querying relative to the local environment, the site
   will need to make one host available to run the emulation of the
   FINGER service.  Although the resulting query will ultimately be
   directed to the remote ESnet DSA, the search will appear to be local
   to the users at that site.  For example, a user on a workstation at
   site XYZ could type the following, omitting their local domain name
   as this is implied:

      finger jones@wp

   This will retrieve information about user Jones at site XYZ (wp is
   the name or alias of a host at site XYZ, i.e. wp.XYZ.GOV).  The site
   coordinator will need to contact the ESnet DSA manager to arrange the
   set up for this service.

2.7.5.3.  Limitations of Using ESnet Services

   Since the ESnet DSA will potentially be mastering information on
   behalf of numerous backbone sites, limits will need to be placed on
   the volume of site information stored in the ESnet DSAs.  These are
   enforced to ensure DSA responsiveness, as well as to reduce
   administrative maintenance.  The limits are:

                 Item                       Maximum Limit
                 ----                       -------------
                 X.500 Organizations                    1
                 Organizational Units                  50
                 Organizational Unit Depth              3
                 Object Entries                     5,000
                 Update Frequency                 1 Month
                 Aliases                              n/a
                 Object/Attribute Access Control      n/a

   One week before each monthly update cycle, a message will be sent on
   the [e-mail] mailer to remind the sites that an update cycle
   is approaching.  If no changes are required to the site information,
   the reminder message can be ignored and the existing version of this
   information will be used. If the information is to be updated, a
   complete replacement of all information must be supplied to the ESnet
   DSA manager before the next update cycle.  More detailed information
   and a sample of a site-supplied data file can be found in Appendix D.

2.8.  ESnet Running a Level-0 DSA for c=US

   For ESnet to provide high quality X.500 services to the ESnet
   community, the ESnet DSAs must operate as Level-0 (first level) DSAs.
   It is currently planned that these DSAs will act as slave, Level-0
   DSAs to PSI's master, Level-0 DSAs.  Once the ESnet DSAs are in



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


   production service, it is recommended that directly connected ESnet
   backbone sites operating their own X.500 DSAs configure them with one
   of the ESnet DSAs as their parent DSA.  This provides several
   advantages to the ESnet community:

   1.  The ESnet DSAs will be monitored by the NERSC's 24-hour
       Operations Staff.  Additionally, ESnet plans to deploy two
       (2) DSAs in geographically disperse locations to ensure
       reliability and availability.

   2.  All queries to Level-0 DSAs remain within the ESnet high-speed
       backbone.

   3.  If network connectivity is lost to all external Level-0 DSAs,
       X.500 Level-0 connectivity will still exist within the ESnet
       backbone.

2.9.  X.500 Registration Requirements