Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 1330

Recommendations for the Phase I Deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESNET Community

Pages: 87
Informational
Part 1 of 3 – Pages 1 to 25
None   None   Next

Top   ToC   RFC1330 - Page 1
Network Working Group                        ESCC X.500/X.400 Task Force
Request for Comments: 1330      ESnet Site Coordinating Committee (ESCC)
                                         Energy Sciences Network (ESnet)
                                                                May 1992


             Recommendations for the Phase I Deployment of
                   OSI Directory Services (X.500) and
                 OSI Message Handling Services (X.400)
                       within the ESnet Community


Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Overview

   The Energy Sciences Network (ESnet) is a nation-wide computer data
   communications network managed and funded by the United States
   Department of Energy, Office of Energy Research (U.S. DOE/OER), for
   the purpose of supporting multiple program, open scientific research.
   ESnet is intended to facilitate remote access to major Energy
   Research (ER) scientific facilities, provide needed information
   dissemination among scientific collaborators throughout all ER
   programs, and provide widespread access to existing ER supercomputer
   facilities.

   Coordination of ER-wide network-related technical activities over the
   ESnet backbone is achieved through the ESnet Site Coordinating
   Committee (ESCC). This committee is comprised of one technical
   contact person from each backbone site, as well as some members of
   the ESnet management and networking staff.  As the need for new
   levels of ESnet services arise, the ESCC typically creates task
   forces to investigate and research issues relating to these new
   services.  Each task force usually results in a whitepaper which
   makes recommendations to the ESnet community on how these services
   should be deployed to meet the mission of DOE/OER.

   This RFC is a near verbatim copy of the whitepaper produced by the
   ESnet Site Coordinating Committee's X.500/X.400 Task Force.

Table of Contents

   Status of this Document  .......................................    4
   Acknowledgments  ...............................................    4
Top   ToC   RFC1330 - Page 2
   1  Introduction  ...............................................    5
   1.1  Abstract and Introduction  ................................    5
   1.2  Structure of this Document  ...............................    5
   2  X.500 - OSI Directory Services  .............................    6
   2.1  Brief Tutorial  ...........................................    6
   2.2  Participation in the PSI White Pages Pilot Project  .......    7
   2.3  Recommended X.500 Implementation  .........................    7
   2.4  Naming Structure  .........................................    8
   2.4.1  Implications of the Adoption of RFC-1255 by PSI  ........    9
   2.4.2  Universities and Commercial Entities  ...................   10
   2.4.3  Naming Structure Below the o=<site> Level  ..............   10
   2.5  Information Stored in X.500  ..............................   13
   2.5.1  Information Security  ...................................   14
   2.6  Accessing the X.500 Directory Service  ....................   14
   2.6.1  Directory Service via WHOIS  ............................   15
   2.6.2  Directory Service via Electronic Mail  ..................   15
   2.6.3  Directory Service via FINGER  ...........................   15
   2.6.4  Directory Service via Specialized Applications  .........   15
   2.6.5  Directory Service from PCs and MACs  ....................   16
   2.7  Services Provided by ESnet  ...............................   16
   2.7.1  X.500 Operations Mailing List  ..........................   17
   2.7.2  Accessing the X.500 Directory  ..........................   17
   2.7.3  Backbone Site Aliases  ..................................   18
   2.7.4  Multiprotocol Stack Support  ............................   18
   2.7.5  Managing a Site's X.500 Information  ....................   19
   2.7.5.1  Open Availability of Site Information  ................   19
   2.7.5.2  Access Methods for Local Users  .......................   19
   2.7.5.3  Limitations of Using ESnet Services  ..................   20
   2.8  ESnet Running a Level-0 DSA for c=US  .....................   20
   2.9  X.500 Registration Requirements  ..........................   21
   2.10  Future X.500 Issues to be Considered  ....................   21
   2.10.1  ADDMDS Interoperating with PRDMDS  .....................   21
   2.10.2  X.400 Interaction with X.500  ..........................   21
   2.10.3  Use of X.500 for NIC Information  ......................   22
   2.10.4  Use of X.500 for Non-White Pages Information  ..........   22
   2.10.5  Introduction of New X.500 Implementations  .............   22
   2.10.6  Interaction of X.500 and DECdns  .......................   22
   3  X.400 - OSI Message Handling Services  ......................   23
   3.1  Brief Tutorial  ...........................................   23
   3.2  ESnet X.400 Logical Backbone  .............................   25
   3.3  Naming Structure  .........................................   25
   3.3.1  Participating in the ESnet Private Management Domain  ...   25
   3.3.2  Operating a Site Private Management Domain  .............   26
   3.3.3  Detailed Name Structure  ................................   26
   3.4  X.400 Routing  ............................................   26
   3.4.1  Responsibilities in Operating an X.400 PRMD MTA  ........   28
   3.4.2  Responsibilities in Operating an X.400 Organizational MTA   29
   3.5  Services Provided by ESnet  ...............................   29
Top   ToC   RFC1330 - Page 3
   3.5.1  X.400 Operations Mailing List  ..........................   30
   3.5.2  MTA Routing Table on ESnet Information Server  ..........   30
   3.5.3  MTA Routing Table Format  ...............................   30
   3.5.4  Gateway Services and Multiprotocol Stack Support  .......   30
   3.5.5  Registering/Listing your PRMD or Organizational MTA with
          ESnet  ..................................................   31
   3.6  X.400 Message Routing Between ADMDS and PRMDS  ............   32
   3.7  X.400 Registration Requirements  ..........................   32
   3.8  Future X.400 Issues to be Considered  .....................   33
   3.8.1  X.400 Mail Routing to International DOE Researchers  ....   33
   3.8.2  X.400 (1984) and X.400 (1988)  ..........................   33
   3.8.3  X.400 Interaction with X.500  ...........................   33
   4  OSI Name Registration and Issues  ...........................   33
   4.1  Registration Authorities  .................................   34
   4.2  Registration Versus Notification  .........................   34
   4.3  Sources of Nationally Unique Name Registration  ...........   35
   4.4  How to Apply for ANSI Organization Names  .................   35
   4.5  How to Apply for GSA Organization Names  ..................   36
   4.5.1  GSA Designated Agency Representatives  ..................   36
   4.5.2  Forwarding of ANSI Registrations to GSA  ................   37
   4.6  How to Apply for U.S. DOE Organization Names  .............   37
   4.7  Why Apply for a Trademark with the PTO?  ..................   38
   4.8  How to Apply for a Trademark with the PTO  ................   38
   4.9  Future Name Registration Issues to be Considered  .........   39
   4.9.1  ANSI Registered ADMD and PRMD Names  ....................   39
   Glossary  ......................................................   40
   Appendix A:  Current Activities in X.500  ......................   49
   Appendix B:  Current Activities in X.400  ......................   55
   Appendix C:  How to Obtain QUIPU, PP and ISODE  ................   58
   Appendix D:  Sample X.500 Input File and Restricted Character
                List  .............................................   65
   Appendix E:  ESnet Backbone Sites  .............................   68
   Appendix F:  Local Site Contacts for DOE Naming Authorities  ...   70
   Appendix G:  Recommended Reading  ..............................   77
   Appendix H:  Task Force Member Information  ....................   83
   Security Considerations  .......................................   86
   Authors' Addresses  ............................................   86
Top   ToC   RFC1330 - Page 4
               Recommendations for the Phase I Deployment of
                    OSI Directory Services (X.500) and
                   OSI Message Handling Services (X.400)
                        within the ESnet Community

         ESnet Site Coordinating Committee X.500/X.400 Task Force

                                Version 1.1

                                March 1992

Status of this Document

   This document makes recommendations for the Phase I deployment of OSI
   Directory Services and OSI Message Handling Services within the ESnet
   Community.  This document is available via anonymous FTP on the ESnet
   Information Server (nic.es.net, 128.55.32.3) in the directory
   [ANONYMOUS.ESNET-DOC] in the file ESNET-X500-X400-VERSION-1-1.TXT.
   The distribution of this document is unlimited.

Acknowledgments

   The following individuals have participated in and contributed to the
   ESCC X.500/X.400 Task Force.  Several of these individuals have also
   authored portions of this document.  See Appendix H for additional
   information regarding task force members and contributing authors.

   Allen Sturtevant (Chair)  Lawrence Livermore National Laboratory
   Bob Aiken                 U.S. DOE/OER/SCS (now with NSF)
   Joe Carlson               Lawrence Livermore National Laboratory
   Les Cottrell              Stanford Linear Accelerator Center
   Tim Doody                 Fermi National Accelerator Laboratory
   Tony Genovese             Lawrence Livermore National Laboratory
   Arlene Getchell           Lawrence Livermore National Laboratory
   Charles Granieri          Stanford Linear Accelerator Center
   Kipp Kippenhan            Fermi National Accelerator Laboratory
   Connie Logg               Stanford Linear Accelerator Center
   Glenn Michel              Los Alamos National Laboratory
   Peter Mierswa             Digital Equipment Corporation
   Jean-Noel Moyne           Lawrence Berkeley Laboratory
   Kevin Oberman             Lawrence Livermore National Laboratory
   Dave Oran                 Digital Equipment Corporation
   Bob Segrest               Digital Equipment Corporation
   Tim Streater              Stanford Linear Accelerator Center
   Mike Sullenberger         Stanford Linear Accelerator Center
   Alan Turner               Pacific Northwest Laboratory
   Linda Winkler             Argonne National Laboratory
   Russ Wright               Lawrence Berkeley Laboratory
Top   ToC   RFC1330 - Page 5
1.  Introduction

1.1.  Abstract and Introduction

   This document recommends an initial approach for the Phase I
   deployment of OSI Directory Services (X.500) and OSI Message Handling
   Services (X.400) within the ESnet community.  It is anticipated that
   directly connected ESnet backbone sites will participate and follow
   the suggestions set forth in this document.

   Section 7 of the "ESnet Program Plan" (DOE/OER-0486T, dated March
   1991) cites the need for further research and investigation in the
   areas of electronic mail and directory services.  The ESCC
   X.500/X.400 Task Force was created to address this need.
   Additionally, the task force is addressing the issues of a
   coordinated, interoperable deployment of OSI Directory Services and
   OSI Message Handling within the entire ESnet community.  Since only a
   small subset of this community is actively pursuing these avenues,
   considerable effort must be made to establish the necessary "base" to
   build upon.  If directly connected ESnet sites participate in these
   services, a consistent transition path will be ensured and the
   services provided will be mutually valuable and useful.

   X.500 and X.400 are continuously evolving standards, and are
   typically updated every four years.  U.S. GOSIP (Government OSI
   Profile) Requirements are updated to define additional functionality
   as needed by the U.S. Federal Government, usually every two years.
   As the X.500 and X.400 standards evolve and U.S. GOSIP Requirements
   are extended, consideration must be given as to the effect this may
   have on these existing services in the ESnet community.  At these
   cross-roads, or when a sizeable increase in service functionality is
   desired, another "phase of deployment" may be in order.  In this
   sense, there isn't a specific "final phase" goal, but rather several
   new releases (updates) to the level of existing services.

1.2.  Structure of this Document

   X.500 is presented first.  The issues of DSA (Directory Service
   Agent) deployment, DSA registration, naming schema, involvement in
   the PSI White Pages Pilot Project, recommended object classes,
   recommended attribute types, information security, search
   optimization, user friendly naming and update frequency are
   addressed.

   In the area of X.400, issues relating to MTA (Message Transfer Agent)
   deployment, ESnet X.400 well-known entry points, ESnet backbone site
   X.400 well-known entry points, MTA registration, naming hierarchy,
   PRMD peering, bidirectional X.400-SMTP relaying and
Top   ToC   RFC1330 - Page 6
   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
Top   ToC   RFC1330 - Page 7
   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
Top   ToC   RFC1330 - Page 8
   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
Top   ToC   RFC1330 - Page 9
   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
Top   ToC   RFC1330 - Page 10
   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".

2.4.3.  Naming Structure Below the o=<site> Level

   The structure of the subtree below the organization's node in the DIT
   is a matter for the local organization to decide.  A site's DSA
Top   ToC   RFC1330 - Page 11
   manager will probably want to enlist input from others within the
   organization before deciding how to structure the local DIT.

   Some organizations currently participating in the Pilot have
   established a simple structure, choosing to limit the number of
   organizational units and levels of hierarchy.  Often this is done in
   order to optimize search performance.  This approach has the added
   benefit of insulating the local DIT from administrative restructuring
   within the organization.  Others have chosen to closely model their
   organization's departmental structure.  Often this approach seems
   more natural and can enhance the information obtained from browsing
   the Directory.

   Below are experiences from current DSA managers, describing the way
   they structured their local DIT and the reasons for doing so.  A site
   may find this information helpful in determining how to structure
   their local DIT.  Ultimately this decision will depend upon the needs
   of the local organization and expectations of Directory usage.

   Valdis Kletnieks of the Virginia Polytechnic Institute:

      "For Virginia Tech, it turned out to be a reasonably
      straightforward process.  Basically, the University is
      organized on a College/Department basis.  We decided to model
      that "real" structure in the DIT for two major reasons:

      "(a) It duplicates the way we do business, so interfacing the
      X.500 directory with the "real world" is easier.

      "(b) With 600+ departmental units and 11,000+ people (to be
      30,000+ once we add students), a "zero" (everybody at top) or
      "one" deep (600 departments at top) arrangement just didn't
      hack it - it was deemed necessary that you be able to do a
      some 120 or 140 county office entries under the Extension
      service, it's a BIT unwieldy there).  However, with some 20
      college-level entries at the top, and the "average" college
      having 30 departments, and the "average" department being from
      10 to 40 people, it works out pretty well."

   Jeff Tannehill of Duke University:

      "Our DIT is flat.  We get the entire database of people at Duke
      from Tel-Com and just put everyone directly under "O=Duke
      University".

      "Actually, there is an exception, when the DSA was first set up
      and we had not received a database yet, I configured the DIT to
      include "OU=Computer Science", under which myself and one other
Top   ToC   RFC1330 - Page 12
      System Administrator have entries.  Upon getting the database
      for everyone else I decided not to attempt to separate the
      people in the database into multiple ou's."

   Joe Carlson of Lawrence Livermore National Laboratory:

      "We tried both flat (actually all under the same OU) and
      splitting based on internal department name and ended up with
      flat.  Our primary reason was load and search times, which were
      2-3 times faster for flat organization."

   Paul Mauvais of Portland State University:

      "We originally set up our DIT by simply loading our campus
      phone book into one level down from the top (e.g. OU=Faculty
      and Staff, OU=Students, OU=Computing Services).

      "I'd love to have an easy way to convert our flat faculty and
      staff area into departments and colleges, but the time to
      convert the data into the separate OU's is probably more than I
      have right now."

   Mohamed Ellozy of Dana-Farber Cancer Institute:

      "Here we have a phone database that includes department, so we
      got the ou's with no effort.  We thus never went the flat space
      way."

   Dan Moline of TRW:

      "Well - we're still in the process of defining our DIT.  TRW
      comes under the international companies DBA.  Our part under
      the PSI White Pages Pilot defines the DIT for our space and
      defense organization here in Redondo Beach (however, I
      organized the structure to adhere to TRW corporate).  We input
      from our manpower DB for our S&D personnel.  We're trying to
      get corporate's DB for possible input.

      "However, arranging your DIT by organizations (at least for
      corps) presents a problem; things are always being reorganized!
      We were DSO now we're SSO!!!  We still have some of our old
      domain name for DNS tied to organizations that have not existed
      for years!

      "So we are currently redesigning our DIT to try to fit NADF 175
      (something more geographically).  Our reasoning was that
      organizations may change but buildings and localities do not."
Top   ToC   RFC1330 - Page 13
   Ruth Lang of SRI:

      "There has been no SRI-wide policy or decision to participate
      in the PSI White Pages Pilot.  @c=US@O=SRI International
      supports the information for one OU only (i.e., a local policy
      and decision).  In order to not give the false impression that
      all SRI information was contained under this O=SRI
      International, I used OU=Network Information Systems Center.
      If I were to structure the DIT for all of SRI, I'm sure that my
      thinking would yield a much different structure."

   Russ Wright of Lawrence Berkeley Laboratory:

      "Since we don't have much organizational information in current
      staff database, I have to stick to a fairly flat structure.  I
      have two OUs.  One is for permanent staff, the other is for
      guests (there is a flag in our database that is set for
      guests).

      "I may add an additional level of OUs to our current structure.
      The top level would contain different 'types' of information.
      For example, one OU may be 'Personnel', another may be called
      publications).  Staff and Guests would reside under the
      Personnel OU."

   Peter Yee of NASA Ames:

      "I broke up my DIT at the NASA Center level.  NASA is made of
      nearly 20 Centers and Facilities.  The decision to break up at
      this level was driven by several factors:

      "1.  Control of the local portion of the DIT should reside with
      the Center in question, particularly since the Center probably
      supplies the data in question and controls the matching DSA.

      "2.  Each Center ranges in size from 1,000 to 16,000 persons.
      This seems to be the range that works well on moderate sized
      UNIX servers.  Smaller would be a waste, larger would require
      too much memory.

      "3.  Representatives from several Centers have contacted me
      asking if they could run their own DSAs so that they can
      experiment with X.500.  Thus the relevant DSA needs to be under
      their control."

2.5.  Information Stored in X.500

   The Phase I deployment of X.500 should be limited to "white pages"-
Top   ToC   RFC1330 - Page 14
   type information about people.  Other types of objects can be added
   in later Phases, or added dynamically as the need arises.

   To make X.500 truly useful to the ESnet community as a White Pages
   service, it is recommended that the following minimum information
   should be stored in the X.500 database:

   Information   ASN.1 Attribute Type      Example
   -----------   --------------------      -------
   Locator Info  commonName                Allen Sturtevant
                 surname                   Sturtevant
                 postalAddress             LLNL
                                           P.O. Box 5509, L-561
                                           Livermore, CA 94551
                 telephoneNumber           +1 510 422 8266
                 facsimileTelephoneNumber  +1 510 422 0435

   E-Mail Info   rfc822Mailbox             Sturtevant@es.net
                 mhsORAddresses            /PN=Allen Sturtevant/O=NERSC/
                                             /PRMD=ESnet/ADMD= /C=US/
                 otherMailbox              DECnet:  ESNIC::APS

   The above list of attributes comprises a minimum set which is
   recommended for a person's entry.  However, you may chose to omit
   some attributes for reasons of privacy or legality.  Note that the
   X.500 standard requires that the surname and commonName attributes be
   present.  If an individual's phone number and/or address cannot be
   provided, they should be replaced by the site's "Information Phone
   Number" and postal address to allow some means of contacting the
   person.

2.5.1.  Information Security

   It is understood that placing this type of information in X.500 is
   equivalent to putting the "Company Phone Book" on-line in the
   Internet.  Different sites may treat this information differently.
   Some may view it as confidential, while others may view this data as
   open to the public.  In any case, it was recommended that ESnet sites
   discuss the implications with their respective legal departments
   before actually making their information openly available. There
   currently exists minimal access control in several X.500
   implementations.

2.6.  Accessing the X.500 Directory Service

   The PSI White Pages Pilot Project software provides numerous
   interfaces to the information in the X.500 Directory.  Non-
   interactive access mechanisms (e.g. WHOIS, FINGER and Electronic
Top   ToC   RFC1330 - Page 15
   Mail) make use of capabilities or services which already reside on
   many workstations and hosts.  Such hosts could immediately take
   advantage of the X.500 service with no additional software or
   reconfiguration needed.  However, since these methods are non-
   interactive, they only provide a way to search for and read
   information in the Directory but no way to modify information.

2.6.1.  Directory Service via WHOIS

   The Pilot Project software allows you to configure the X.500
   Directory service to be made available via a network port offering an
   emulation of the SRI-NIC WHOIS service.  UNIX-based hosts and VMS
   hosts running Multinet typically come configured with the WHOIS
   service.  Users at their workstations would then be able to issue a
   simple WHOIS command to a known host running a DSA to retrieve
   information about colleagues at their site or at other ESnet sites.
   For example, the command:

      whois -h wp.lbl.gov wright

   will return information about Russ Wright at Lawrence Berkeley Lab.
   It is recommended that all sites which bring up such a service,
   should provide an alias name for the host running their DSA of the
   form <wp.site.domain> for consistency within the ESnet community.

2.6.2.  Directory Service via Electronic Mail

   The Pilot Project software also allows the X.500 Directory service to
   be made available via electronic mail.  A user who sends an
   electronic mail message to a known host running a DSA containing a
   WHOIS-like command on the subject line, would then receive a return
   mail message containing the results of their query.

2.6.3.  Directory Service via FINGER

   The X.500 Directory service could also be made available via the
   FINGER service.  Although this access method does not come with the
   PSI Pilot Project software, several sites have already implemented a
   FINGER interface to the X.500 Directory.  For ease of use and
   consistency, a single FINGER interface should be selected, then
   individual implementations within the ESnet community should conform
   to this interface.

2.6.4.  Directory Service via Specialized Applications

   Many X.500 Directory User Agents (DUAs) are widely available.  Some
   of these come with the PSI Pilot Project software.  Other DUAs, which
   have been developed by third parties to fit into the pilot software,
Top   ToC   RFC1330 - Page 16
   are publicly available.  These user agents support interactive access
   to the X.500 Directory allowing browsing, searching, listing and
   modifying data in the Directory.  However, in most cases, use of
   these DUAs requires the Pilot Project software be installed on the
   host system.  Only a few of these DUAs and their capabilities are
   described below.

   o  DISH - A User Agent which provides a textual interface to the
      X.500 Directory.  It gives full access to all elements of the
      Directory Access Protocol (DAP) and as such may be complex for
      novice users.  DISH is most useful to the DSA administrator.

   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,
Top   ToC   RFC1330 - Page 17
   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:  x500-ops@es.net
      To subscribe:        x500-ops-request@es.net

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):
Top   ToC   RFC1330 - Page 18
      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
Top   ToC   RFC1330 - Page 19
   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.
Top   ToC   RFC1330 - Page 20
   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 x500-ops@es.net 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
Top   ToC   RFC1330 - Page 21
   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

   X.500 organization names must be nationally unique if they appear
   directly below the c=US level in the DIT structure.  Nationally
   unique names must be registered through an appropriate registration
   authority, i.e., one which grants nationally unique names.

   X.500 organizational unit names need to be unique relative to the
   node directly superior to them in the DIT.  Registration of these
   names should be conducted through the "owner" of the superior node.

   The registration of X.500 names below the organization level are
   usually a local matter.  However, all siblings under a given node in
   the DIT must have unique RDNs.

   See Section 4 for a more complete description of OSI registration
   issues and procedures.

2.10.  Future X.500 Issues to be Considered

2.10.1.  ADDMDS Interoperating with PRDMDS

   This is a problem which currently does not have an answer.  The issue
   of Administrative Directory Management Domains (ADDMDs) interacting
   with Private Directory Management Domains (PRDMDs) is just beginning
   to be investigated by several groups interested in solving this
   problem.

2.10.2.  X.400 Interaction with X.500

   The current level of understanding is that X.400 can benefit from the
Top   ToC   RFC1330 - Page 22
   use of X.500 in two ways:

   1.  Lookup of message recipient information.

   2.  Lookup of message routing information.

   X.400 technology and products, as they stand today, do not support
   both of these features in a fully integrated fashion across multiple
   vendors.  As the standards and technology evolve, consideration will
   have to be given in applying these new functions to the production
   ESnet X.500/X.400 services environment.

2.10.3.  Use of X.500 for NIC Information

   Work is currently being performed in the IETF to place NIC
   information on-line in an Internet-based X.500 service.

2.10.4.  Use of X.500 for Non-White Pages Information

   The PSI White Pages Pilot Project has caused increasing and popular
   use of X.500 as a white pages services within the Internet community.
   However, the X.500 standard provides for much more than just this
   service.  Application processes, devices and security objects are
   just a few of the objects to be considered for future incorporation
   in the global X.500 database.

2.10.5.  Introduction of New X.500 Implementations

   Thought will have to be given to the use of commercial X.500 products
   in the future as QUIPU (the implementation recommended in this paper)
   may not meet all of the needs of the ESnet community.  As commercial
   products mature and become stable, they will have to be incorporated
   into the ESnet X.500 service in a way which ensures interoperability
   and reliability.

2.10.6.  Interaction of X.500 and DECdns

   There is every indication that DECdns and X.500 will interoperate in
   some fashion in the future.  Since there is an evolving DECdns
   namespace (i.e.  OMNI) and an evolving X.500 DIT (i.e. NADF), some
   consideration should be given to how these two name trees will
   interact.  All of this will be driven by the Digital Equipment
   Corporation's decisions on how to expand and incorporate its DECdns
   product with X.500.
Top   ToC   RFC1330 - Page 23
3.  X.400 - OSI Message Handling Services

3.1.  Brief Tutorial

   In 1984 CCITT defined a set of protocols for the exchange of
   electronic messages called Message Handling Systems (MHS) and is
   described in their X.400 series of recommendations.  ISO incorporated
   these recommendations in their standards (ISO 10021).  The name used
   by ISO for their system was MOTIS (Message-Oriented Text Interchange
   Systems).  In 1988 CCITT worked to align their X.400 recommendations
   with ISO 10021.  Currently when people discuss messaging systems they
   use the term X.400.  These two systems are designed for the general
   purpose of exchanging electronic messages in a store and forward
   environment.  The principle use being made of this system today is to
   support electronic mail.  This section will give an overview of X.400
   as used for electronic mail.  In the following sections, the term
   X.400 will be used to describe both the X.400 and MOTIS systems.

   The basic model used by X.400 MHS is that of a Message Transfer
   System (MTS) accessed via a User Agent (UA).  A UA is an application
   that interacts with the Message Transfer System to submit messages on
   behalf of a user.  A user is referred to as either an Originator
   (when sending a message) or a Recipient (when receiving one).  The
   process starts out when an Originator prepares a message with the
   assistance of their UA.  The UA then submits the message to the MTS
   for delivery.  The MTS then delivers the message to one or more
   Recipient UAs.

                    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
       ______      |      _______          _______     |     ______
      |      |     | MTS |       |        |       |    |    |      |
      |  UA  |<----|---->|  MTA  |<------>|  MTA  |<---|--->|  UA  |
      |______|     |     |_______|        |_______|    |    |______|
                   |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|

   The MTS provides the general store-and-forward message transfer
   service. It is made up of a number of distributed Message Transfer
   Agents (MTA).  Operating together, the MTAs relay the messages and
   deliver them to the intended recipient UAs, which then makes the
   messages available to the recipient (user).

   The basic structure of an X.400 message is an envelope and content
   (i.e.  message).  The envelope carries information to be used when
   transferring the message through the MTS.  The content is the piece
   of information that the originating UA wishes delivered to the
   recipient UA.  There are a number of content types that can be
   carried in X.400 envelopes.  The standard user message content type
   defined by X.400 is called the Interpersonal (IP) message.  An IP
Top   ToC   RFC1330 - Page 24
   message consists of two parts, the heading and body.  The heading
   contains the message control information. The body contains the user
   message.  The body may consist of a number of different body parts.
   For example one IP message could carry voice, text, Telex and
   facsimile body parts.

   The Management domain (MD) concept within the X.400 recommendations
   defines the ownership, operational and control boundary of an X.400
   administration.  The collection consisting of at least one MTA and
   zero or more UAs owned by an organization or public provider
   constitutes a management domain (MD).  If the MD is managed by a
   public provider it is called an Administration Management Domain
   (ADMD).  The MD managed by a company or organization is called a
   Private Management Domain (PRMD).  A Private MD is considered to
   exist entirely within one country.  Within that country a PRMD may
   have access to one or more ADMDs.

   Each MD must ensure that every user (i.e UA) in the MD has at least
   one name.  This name is called the Originator/Recipient (O/R) Name.
   O/R Names are constructed from a set of standard attributes:

   o  Country Name

   o  Administration Management Domain

   o  Private Management Domain

   o  Organization Name

   o  Organizational Unit Name

   o  Surname

   o  Given name

   o  Initials

   o  Generational Qualifier

   An O/R name must locate one unambiguous O/R UA if the message is to
   be routed correctly through the Message Transfer Service.  Currently
   each MD along the route a message takes determines the next MD's MTA
   to which the message should be transferred.  No attempt is made to
   establish the full route for a message, either in the originating MD
   or in any other MD that acquires the store and forward responsibility
   for the message.

   Messages are relayed by each MD on the basis of the Management domain
Top   ToC   RFC1330 - Page 25
   portion of their O/R Name until arrival at the recipient MD.  At
   which point, the other attributes in the name are used to further
   route to the recipient UA.  Internal routing within a MD is the
   responsibility of each MD.

3.2.  ESnet X.400 Logical Backbone

   Currently within the ESnet community message handling services are
   implemented with a number of different mail products, resulting in
   what is classically known as an "n-squared" problem.  For example,
   let's say that LLNL only uses QuickMail on site, PPPL only uses
   MAIL-11 (VMS MAIL), and CEBAF only uses SMTP mail.  For LLNL to send
   mail to PPPL and CEBAF, is must support MAIL-11 and SMTP locally on-
   site.  Likewise for PPPL to send mail to LLNL and CEBAF, it must
   support MAIL-11 and QuickMail locally.  Identically, this scenario
   exists for CEBAF.

   To alleviate this problem, a logical X.400 backbone must be
   established through out the entire ESnet backbone.  Then, each ESnet
   backbone site will be responsible for only providing connectivity
   between it's local mail domains (QuickMail, MAIL-11, SMTP Mail, or
   even native X.400) and the logical X.400 backbone.  One of the long-
   term goals is to establish X.400 as the "common denominator" between
   directly connected ESnet backbone sites.



(page 25 continued on part 2)

Next Section