doc: Add RFC documents

1 files changed, 4875 insertions, 0 deletions

diff --git a/doc/rfc/rfc1330.txt b/doc/rfc/rfc1330.txt
new file mode 100644
index 0000000..a761a7e
--- /dev/null
+++ b/doc/rfc/rfc1330.txt
@@ -0,0 +1,4875 @@
+
+
+
+
+
+
+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
+
+
+
+ESCC X.500/X.400 Task Force                                     [Page 1]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   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
+
+
+
+ESCC X.500/X.400 Task Force                                     [Page 2]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ESCC X.500/X.400 Task Force                                     [Page 3]
+
+RFC 1330            X.500 and X.400 Plans for 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
+
+         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
+
+
+
+ESCC X.500/X.400 Task Force                                     [Page 4]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+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
+
+
+
+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".
+
+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
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 10]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   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
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 11]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+      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."
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 12]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   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"-
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 13]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   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
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 14]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   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,
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 15]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   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,
+
+
+
+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:  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):
+
+
+
+
+
+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 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
+
+
+
+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
+
+   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
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 21]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   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.
+
+
+
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 22]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+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
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 23]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   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
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 24]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   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.
+
+3.3.  Naming Structure
+
+   The name-spaces for X.500 and X.400 are completely different and are
+   structured to meet different needs.  The X.500 name-space is
+   typically organized to allow quick, optimized searching; while the
+   X.400 ORname is used to forward an X.400 message through several
+   "levels" of MTAs (X.400 Message Transfer Agents).
+
+   ESnet backbone sites will participate in the X.400 environment
+   through one of two options; either participating in the ESnet Private
+   Management Domain (PRMD) or operating a site PRMD.  For most sites,
+   utilizing the ESnet PRMD will be the simpler and preferable choice.
+
+3.3.1.  Participating in the ESnet Private Management Domain
+
+   ESnet backbone sites participating in the ESnet PRMD will have an
+   X.400 name syntax as follows:
+
+                   /.../O=<site>/PRMD=ESnet/ADMD= /C=US/
+
+   A few examples of a possible X.400 ORnames using the above syntax
+   are:
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 25]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+         /PN=Smith/OU=Computations/O=LLNL/PRMD=ESnet/ADMD= /C=US/
+            /PN=Jones/OU=Physics/O=PPPL/PRMD=ESnet/ADMD= /C=US/
+
+   These sites will operate an MTA at the /O=<organization> level in the
+   name hierarchy.
+
+3.3.2.  Operating a Site Private Management Domain
+
+   ESnet backbone sites which operate a PRMD will have an X.400 name
+   syntax as follows:
+
+                   /.../O=<org>/PRMD=<site>/ADMD= /C=US/
+
+   A few examples of a possible X.400 ORnames using the above syntax
+   are:
+
+              /PN=Smith/O=Computations/PRMD=LLNL/ADMD= /C=US/
+                /PN=Jones/O=Physics/PRMD=PPPL/ADMD= /C=US/
+
+   These sites will operate an MTA at the /PRMD=<PRMD> level in the name
+   hierarchy.  This MTA will peer with the ESnet PRMD MTA.
+
+3.3.3.  Detailed Name Structure
+
+   GOSIP places several limits on allowable ORnames.  After the
+   /O=<organization> name, up to four levels of
+   /OU=<organizational_unit> names are allowed.  The ORname string is
+   then completed with the /PN=<personal_name> field.
+
+   All ORname fields must use characters from the ISO printable
+   character set.  Additionally, the following name length restrictions
+   apply:
+
+                PRMD Names                    16 characters
+                Organization Names            64 characters
+                Organizational Unit Names     32 characters
+                Personal Names                64 characters
+
+      NOTE:  A 40 character limit for Personal Names is now being
+             studied by the CCITT.
+
+   Within these name constraints, the architecting of an organization's
+   name space is a local matter.  Sites are encouraged to consider ease
+   of use and stability when determining their naming structure.
+
+3.4.  X.400 Routing
+
+   In the IP environment a SMTP MTA could use the Domain Name Service
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 26]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   (DNS) to locate connection information for the host closest to the
+   recipient.  With X.400, MTAs must know the remote MTAs name and
+   password along with connection information.  This is because of
+   access control requirements on some X.400 systems.  In X.400 MHS this
+   information will, at some future date, be provided by X.500.  In the
+   mean time the routing and connection process within the X.400
+   community is table driven.  This solution requires a coordination and
+   distribution effort to ensure a quick and reliable update of these
+   tables.
+
+   The current thinking on the problem of X.400 routing is to decompose
+   the X.400 address space into a hierarchy, with each node in this
+   hierarchy representing the entry point for an X.400 domain.  These
+   nodes have been commonly called Well Known Entry Points (WEPs).  Each
+   of these WEPs represent one X.400 MHS domain.  For example:
+
+      /O=LBL/PRMD=ESnet/ADMD= /C=US/
+      /O=NERSC/PRMD=ESnet/ADMD= /C=US/
+      /PRMD=ESnet/ADMD= /C=US/
+      /PRMD=ANL/ADMD= /C=US/
+      /PRMD=PNL/ADMD= /C=US/
+
+   To minimize the number of hops between Originators and Recipients it
+   is the current recommendation of the X.400 community that every PRMD
+   peer with all other PRMDs.
+
+   The ESnet backbone will provide connectivity between multiple PRMDs
+   (the ESnet PRMD and any site operated PRMDs), each with associated
+   well-know entry point MTAs.  Each of these PRMD-level MTAs must be
+   configured with routing and mapping information about each other to
+   enable peer-to-peer PRMD routing.  These routing tables should be
+   updated immediately upon the discovery of new/changed X.400
+   connectivity information.  These tables will be made available to the
+   ESnet community via the ESnet Information Server.  Once placed on-
+   line, a notification message announcing the availability of this new
+   routing information will be sent to every WEP owner via the E-mail
+   mechanism described in Section 3.5.1.  It is recommended that WEP
+   administrators should retrieve this new routing information and
+   update their MTAs within 10 working days.
+
+   The well-known entry point MTA for each PRMD can route down to an
+   Organizational level MTA or laterally to the well-known entry point
+   of a peer PRMD MTA.
+
+   For example, the ESnet MTA would route a message with the address:
+
+               /PN=Funk/OU=CS/O=PPPL/PRMD=ESnet/ADMD= /C=US/
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 27]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   to a well-known entry point for PPPL (O=PPPL).  PPPL must own and
+   operate their own X.400 MTA, and it must be configured to accept
+   X.400 messages from the ESnet MTA.  Thus, the interpretation of
+   remaining "/PN=Funk/OU=CS" is left to the PPPL MTA to route.
+
+   Mail sent from PPPL's MTA would be routed to the ESnet's MTA (PRMD)
+   to be eventually routed to its destination.
+
+   The ESnet MTA will also route to peer MTAs which are well-known entry
+   points for other PRMDs (e.g. ESnet backbone site PRMDs, XNREN, Hughes
+   Air Craft, NASA, CDC).  For example, the ESnet MTA would route a
+   message with the address:
+
+                /PN=Smith/OU=MS/O=RL/PRMD=PNL/ADMD= /C=US/
+
+   to a well-known entry point for PNL (PRMD=PNL).  PNL must own and
+   operate their own X.400 MTA, and it must be configured to accept
+   X.400 messages from the ESnet MTA (as well as possibly other PRMDs).
+   Thus, the interpretation of the remaining "/PN=SMITH/OU=MS/O=RL" is
+   left to the PNL MTA to route.
+
+   Mail sent from PNL's MTA (PRMD) would be routed to the well-known
+   entry point for the PRMD indicated in the destination address.
+
+   Additionally, a site operated PRMD must be able to route mail to any
+   other peer-PRMD within the ESnet community.
+
+3.4.1.  Responsibilities in Operating an X.400 PRMD MTA
+
+   If the X.400 world were to operate exactly as the standard
+   recommends, PRMDs would only peer with other PRMDs when connectivity
+   is available and traffic demand is sufficient, and would utilize ADMD
+   services to reach all other PRMDs.  In reality, many PRMDs will not
+   subscribe to an ADMD service and will only be reachable through PRMD
+   peering.
+
+   Most communities, such as the ESnet, desire the fullest PRMD
+   interconnectivity possible to minimize the need for ADMD services.
+   Community PRMD operational requirements stem from a policy of
+   achieving large scale peering among PRMD operators within the
+   community.
+
+   Work is continuing in the IETF X.400 Operations Working Group to
+   produce an RFC that specifies the operational requirements that must
+   be implemented by X.400 Management Domains.  "Requirements for X.400
+   Management Domains (MDs) Operating in the Global Research and
+   Development X.400 Service", this document is listed in Appendix G.
+   ESnet will comply with all the requirements outlined in this
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 28]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   document.  It is the recommendation that all ESnet PRMDs follow the
+   requirements specified in this document.
+
+   As an overview, this document specifies that each PRMD will provide
+   at least one WEP and that all PRMDs must be interconnected.  There
+   are a number of PRMDs in the International X.400 service that have
+   different communication stack requirements.  For example:
+
+                          Stack 1     Stack 2     Stack 3     Stack 4
+                          -------     -------     -------     -------
+     Transport Layer 4        TP0         TP4    RFC-1006         TP0
+     Network Service 1-3     X.25        CLNS      TCP/IP        CONS
+
+   To meet the requirement that all PRMDs must be interconnected a PRMD
+   must support one or more of the above stacks.  For stacks that are
+   not supported the PRMD must negotiate with another PRMD or ADMD to
+   relay messages to a Management Domain that does support the other
+   stacks.
+
+   The PRMD requirements also suggest that PRMDs support downgrading of
+   X.400 1988 to X.400 1984.  Also, the PRMD must be reachable from the
+   Internet Mail service.  This means the PRMD must maintain an Internet
+   Mail/X.400 gateway.
+
+   In all cases, members of the ESnet community who operate a PRMD
+   should notify ESnet of the WEP and MTA information required to
+   perform peering.
+
+3.4.2.  Responsibilities in Operating an X.400 Organizational MTA
+
+   ESnet will provide PRMD service to the ESnet community.  ESnet will
+   peer with the other PRMDs in the International X.400 service and
+   provide a WEP for the ESnet community.  An Organization/site needs to
+   decide if they are going to comply with the above PRMD requirements
+   or act as an organization associated to the ESnet PRMD.  Minimally,
+   an organizational MTA will only have to support one of the protocol
+   stacks provided by it associated PRMD.  But in all cases, the site
+   will need to provide a WEP and register/list their MTA(s) with ESnet.
+
+3.5.  Services Provided by ESnet
+
+   ESnet will provide PRMD service to those members of the ESnet
+   community who desire it.  ESnet will peer with other PRMDs in the
+   International community (e.g. XNREN, Hughes Air Craft, NASA, CDC) and
+   provide a WEP for the ESnet community; the intent is to provide the
+   fullest PRMD level X.400 services.
+
+   ESnet will deploy two, PRMD level, X.400 MTAs in geographically
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 29]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   disperse locations.  These MTAs will be able to forward mail for
+   directly connected ESnet backbone sites, as well as to and from the
+   peered PRMDs.
+
+3.5.1.  X.400 Operations Mailing List
+
+   ESnet will provide an X.400 operations mailer for announcements and
+   to allow the sharing of X.400 operational information in the ESnet
+   community.
+
+      General discussion:  x400-ops@es.net
+      To subscribe:        x400-ops-request@es.net
+
+3.5.2.  MTA Routing Table on ESnet Information Server
+
+   ESnet will maintain forwarding information about ESnet community MTAs
+   at the /PRMD=<PRMD> or /O=<organization> levels (depending on what
+   level the site MTA is operating).  This information will be available
+   for use in configuring directly connected ESnet site operated MTAs.
+   This information will be made available in a machine independent
+   format on the ESnet Information Server.
+
+3.5.3.  MTA Routing Table Format
+
+   The ESnet staff will determine the details of information format,
+   update frequency, obtaining, and disseminating the information based
+   on operational experience and constraints.
+
+3.5.4.  Gateway Services and Multiprotocol Stack Support
+
+   The ESnet MTAs will minimally support bidirectional SMTP-X.400 mail
+   gateway capabilities, and will operate over the OSI CLNS protocol (as
+   defined by GOSIP) and RFC-1006 stacks.  Configuration and operation
+   of mail protocol gateway functions will be governed by the ESnet
+   staff.
+
+   Backbone site MTAs which service ORnames at the /O=<site> level under
+   the ESnet PRMD must utilize one of the ESnet PRMD supported protocol
+   stacks.  This requirement assures that all users of the ESnet PRMD
+   will be able to communicate to one another via the ESnet PRMD MTA.
+
+   Backbone site MTAs which service ORnames in PRMDs other than
+   /PRMD=ESnet must utilize the OSI CLNS stack for GOSIP conformance.
+   Use of the RFC-1006 stack is optional.  This requirement assures that
+   all PRMDs in the ESnet community will be able to peer with the ESnet
+   PRMD.
+
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 30]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+3.5.5.  Registering/Listing your PRMD or Organizational MTA with ESnet
+
+   To provide for the connection and routing requirements in X.400 you
+   will need to register/list your MTA with ESnet.  This information
+   will be maintained in tables on the ESnet Information Server.  ESnet
+   will also maintain information on the International X.400 service.
+   ESnet will use the same format for information as maintained by the
+   International X.400 service.  This is described in detail in a IETF
+   X.400 operations paper "Routing Coordination for X.400 MHS Services
+   within a Multiprotocol/Multinetwork Environment".  This paper is a
+   working draft, see Appendix G.  It describes a machine independent
+   form for distribution of X.400 information.
+
+   There are three tables that must be maintained and exchanged by the
+   top level WEPS.
+
+   1.  The Community Document
+
+   2.  The WEP Document
+
+   3.  The Domain Document
+
+   ESnet will submit these documents to the International X.400
+   community on behalf of the ESnet Community.  If an ESnet PRMD wishes
+   to peer with the International PRMDs they will need to submit these
+   documents to that community.
+
+   The Community document is used to list the central coordination point
+   and file server where all MHS documents will be stored.  It also
+   lists the communication stacks used by the MHS community.  This
+   document will be submitted to the International X.400 service by
+   ESnet for the ESnet Community.  ESnet PRMDs and Organizations do not
+   need to submit this form to ESnet.  If an ESnet PRMD wishes to peer
+   with the International X.400 service then they must submit this form
+   to that community.
+
+   Each ESnet MHS domain will need to submit a WEP and Domain Document
+   to ESnet.  The WEP document is used to list the WEPs used by an ESnet
+   MHS domain.  It will contain all the information that is needed for
+   MTA connection and access control.  ESnet will submit the ESnet
+   community WEP and Domain Documents to the International X.400
+   service.  The WEP document consists of a list of WEPs, with the
+   following information for each one:
+
+   o  The MTA Name
+
+   o  Password
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 31]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   o  Which MTS supported
+
+   o  Which standard, 84 and/or 88
+
+   o  Connection information outbound
+
+   o  Connection information inbound
+
+   o  Computer system information
+
+   o  Point of contact
+
+   The Domain Document specifies all the X.400 domains managed by a
+   site.  It indicates the person responsible and which WEP services
+   which Domain.  This document contains the following information
+   repeated for each Domain:
+
+   o  X.400 Domain
+
+   o  Point of Contact
+
+   o  Relaying WEP(s)
+
+3.6.  X.400 Message Routing Between ADMDS and PRMDS
+
+   While ESnet will provide X.400 routing service for systems, it cannot
+   provide routing via commercial X.400 carriers at this time.  The
+   FTS-2000 charge for routing X.400 messages is $.45 (US) plus X.25
+   packet charges.  This could result in a charge of several dollars for
+   large messages, a real possibility with the multi-media capacity of
+   X.400.  The payment of this fee is not within the charter of ESnet
+   and the provision of a charging mechanism to charge member sites is
+   not currently contemplated.
+
+3.7.  X.400 Registration Requirements
+
+   It is recommended by the CCITT that all X.400 PRMD names be
+   nationally unique.  This is a current CCITT agreement and allows
+   direct PRMD-PRMD peer routing.  Since national uniqueness is
+   required, registration should be performed through an appropriate
+   registration authority (such as ANSI).
+
+   X.400 organization names must be unique within a PRMD.  There is no
+   need for national uniqueness.  Registration of an X.400 organization
+   name should be conducted through the PRMD operator.
+
+   The registration of X.400 names below the organization level are
+   usually a local matter.  Uniqueness within the context of a superior
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 32]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   name should always be maintained.
+
+   See Section 4 for a more complete description of OSI registration
+   issues and procedures.
+
+3.8.  Future X.400 Issues to be Considered
+
+3.8.1.  X.400 Mail Routing to International DOE Researchers
+
+   Currently there are DOE researchers located in Switzerland, Japan,
+   Germany, China and Brazil.  PRMD level connectivity to these
+   international locations does not exist presently.  Since ESnet is not
+   chartered to pay for commercial X.400 services on behalf of the ESnet
+   community, "buying" this service is not a viable option.
+
+   There are efforts taking place to provide international X.400 service
+   over the (international) Internet.  Once this becomes fully
+   operational, further research will have to be performed to see if
+   this provides the X.400 connectivity needed to support the DOE
+   researchers located abroad.
+
+3.8.2.  X.400 (1984) and X.400 (1988)
+
+   The ESnet MTAs will initially support the 1984 version of the X.400
+   standard.  As the use of 1988 X.400 becomes more prevalent, support
+   for the newer standard will need to be addressed.  One important
+   point, once the ESnet MTAs become 1988 X.400 compliant, they will
+   also have so support "downgrading" to 1984 X.400 to ensure reliable
+   X.400 mail delivery to the ESnet community.
+
+3.8.3.  X.400 Interaction with X.500
+
+   This is discussed in Section 2.10.2.
+
+4.  OSI Name Registration and Issues
+
+   Implementing OSI services requires that certain information objects
+   (e.g., people, information processing systems and applications) must
+   be unambiguously identifiable on a global basis.  These objects may
+   be defined by a variety of organizations, e.g., ISO/IEC, CCITT,
+   commercial, and government.
+
+   To meet this requirement ISO/IEC and CCITT have established a
+   hierarchical structure of names (a tree).  The top level of the
+   naming tree, shared by ISO and CCITT, represents the global naming-
+   domain.  Naming domains are managed by registration authorities.  A
+   registration authority can delegate authority for part of its
+   naming-domain to another (lower level) registration authority, thus
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 33]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   forming the tree.
+
+   Each object can be given a unique and unambiguous name by registering
+   the object's name with an OSI registration authority at an
+   appropriate level in the naming tree.
+
+   OSI name registration authorities and their procedures are expected
+   to change over time.  Since names are intended to be stable, these
+   changes (hopefully!) will have minimal impact on existing OSI name
+   registrations.
+
+   This section describes the role of OSI registration authorities, the
+   difference between a "registration" and a "notification", and sources
+   of nationally unique names.  Information about three OSI name
+   registration authorities; the American National Standards Institute
+   (ANSI), the General Services Administration (GSA), and the U.S.
+   Department of Energy (U.S. DOE); are given.
+
+   Registration of a name often requires stating a "right" to that name.
+   However, an OSI name registration does not guarantee legal name
+   rights. Name rights should be reviewed by legal experts prior to
+   registration. Information about the U.S. Department of Commerce,
+   Patent and Trademark Office (PTO) (potentially useful in asserting or
+   defending name rights) is given below.
+
+4.1.  Registration Authorities
+
+   OSI names are obtained through OSI name registration authorities by a
+   registration process.  The selection of which particular registration
+   authority to use is determined by the desired level of the OSI name
+   in the naming hierarchy, possible restrictions on the names allocated
+   by each registration authority, and the applicability rules (will
+   they service your request) of each registration authority.
+
+   An OSI name registration authority allocates OSI names from the
+   particular naming-domain it controls.  Every registration authority
+   can trace its naming authority to its parent registration authority,
+   and ultimately to the top (global) level of the naming hierarchy.
+
+4.2.  Registration Versus Notification
+
+   Registering an OSI name guarantees its uniqueness and lack of
+   ambiguity. For a name to be useful however, other parties (besides
+   the registration authority) will need to be notified of the name and
+   its usage.
+
+   There is a clear distinction between registration (obtaining an OSI
+   name) and notification (informing others of a name and its use).
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 34]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   Often the term "registration" is used to describe both activities,
+   this is a potential source of confusion.
+
+   For example, NADF and PSI (see Section 2) are not OSI registration
+   authorities.  NADF may operate state registration authorities in the
+   future, if delegated that administrative right by the states.  PSI
+   operates an X.500 pilot project and needs to be notified of
+   registered names when organizations join their pilot.
+
+   X.400 ADMD operators are also not OSI registration authorities,
+   although they accept notification of X.400 PRMD names used by their
+   customers.
+
+   The PTO is not an OSI registration authority.  PTO names have no
+   meaning in an OSI context.
+
+4.3.  Sources of Nationally Unique Name Registration
+
+   There are four potential sources of nationally unique names which are
+   of interest to the ESnet community.  These are ANSI, GSA, U.S. DOE
+   and the states.  An overview of the ANSI, GSA, and U.S. DOE
+   procedures are given in later sections.
+
+   In order to maintain national uniqueness "constructed name syntax" is
+   used by GSA, U.S. DOE, and the states.  The form of each name is
+   shown below, "name" is the name presented to the registration
+   authority for registration.
+
+   1.  ANSI names are of the form "name".
+
+   2.  GSA names are of the form "GOV+name".
+
+   3.  U.S. DOE names are of the form "GOV+USDOE+name".
+
+   4.  State names are of the form "CA+name" (using California).
+
+   State name registration authorities are not in operation at this
+   time.  The use of U.S. DOE as a nationally unique name registration
+   source is not recommended due to the awkwardness of a double
+   constructed name.
+
+4.4.  How to Apply for ANSI Organization Names
+
+   ANSI is the root U.S. source of OSI recognized nationally unique
+   organization names.  ANSI registration costs $2500 and results in
+   both an alphanumeric name and an associated numeric name.  These
+   names may be used for a variety of purposes in X.400, X.500, and
+   other OSI services.
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 35]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   For ANSI OSI organization name registration forms and instructions,
+   you should send your request to:
+
+                American National Standards Institute, Inc.
+                Attn:  Beth Somerville
+                OSI Registration Coordinator
+                11 West 42nd Street
+                New York, NY   10036
+                Phone:  (212) 642-4976
+
+   ANSI registration procedures include a 90 day public review period
+   during which name requests can be easily challenged.
+
+   There is a mechanism to forward ANSI requests to the GSA, it is
+   discussed in the GSA section below.
+
+4.5.  How to Apply for GSA Organization Names
+
+   GSA is the registration authority for government use of GOSIP, their
+   registration services are free for federal government organizations.
+   Names assigned by GSA always begin with the characters "GOV+" and are
+   limited to 16 characters.  By agreement with ANSI, these GSA assigned
+   names are national unique.
+
+   For GSA OSI Organization Name registration forms and instructions,
+   you should send your request to:
+
+                  General Services Administration
+                  Office of Telecommunications Services
+                  Registration Services, Room 1221-L KBA
+                  18th and F Streets, N.W.
+                  Washington, D.C. 20405
+
+4.5.1.  GSA Designated Agency Representatives
+
+   When preparing the GSA registration form a designated agency
+   representative must sign where it says "Registration Official Name
+   and Signature".  GSA will refuse requests missing this signature.
+
+   The GSA designated Agency Representative for the Department of Energy
+   is:
+
+
+
+
+
+
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 36]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+                    Steve Hackman
+                    Electronics Engineer
+                    U.S. Department of Energy
+                    AD-241.3/GTN
+                    Washington, D.C. 20585
+                    Office Phone:  (301) 903-6111
+                    Office FAX:    (301) 903-4125
+                    E-Mail:  hackman@gosip.xosi.doe.gov
+
+4.5.2.  Forwarding of ANSI Registrations to GSA
+
+   ANSI registration requests can be forwarded automatically to the GSA.
+   This is the equivalent of registering with both ANSI and GSA.  The
+   result is two nationally unique OSI name registrations, "name" from
+   ANSI and "GOV+name" from GSA.
+
+   There is no GOSIP requirement for GSA registration but many feel the
+   additional GSA registration may be useful.
+
+   Assuming your organization is a federal government organization,
+   answer the last three questions on the ANSI registration form as
+   shown below:
+
+   1.  Do you wish the information supplied in the request to remain
+       confidential?  NO.
+
+   2.  Do you wish to have your organization name registered with the
+       U.S. GOSIP Registration Authority (a.k.a. GSA)?  YES.
+
+   3.  Is your organization an organization of the Federal Government?
+       YES.
+
+   You must indicate on the application form the approval of the GSA
+   designated agency representative (Steve Hackman).  He does not sign
+   as "Signature of Requestor", but some notation of his approval must
+   be attached or GSA will reject the forwarded application.
+
+4.6.  How to Apply for U.S. DOE Organization Names
+
+   ESnet sites are encouraged to review the DOE GOSIP procedures and
+   guidelines in planning their GOSIP activities.  This document does
+   not conflict with current DOE GOSIP policies.
+
+   DOE can assign nationally unique names which are prefixed by the
+   string "GOV+USDOE+".  Use of this name source is not recommended;
+   there is no apparent advantage in using U.S. DOE over GSA as a source
+   of nationally unique names.
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 37]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   Copies of current U.S. DOE GOSIP policies, guidelines, and
+   registration forms may be obtained through site DOE naming
+   authorities or Steve Hackman.
+
+4.7.  Why Apply for a Trademark with the PTO?
+
+   Legal issues may arise concerning the rights to use a desired name.
+   OSI name registrations are not intended to "legally protect" name
+   usage rights; that is not their function.
+
+   Consultation with legal experts concerning the rights to use a name
+   being registered is strongly advised, this recommendation does not
+   offer specific legal guidance.  Applying for a trademark may be
+   considered as a means to assert or protect the rights to a name.
+
+   Per the PTO trademark application instructions there may be several
+   benefits in obtaining a trademark.
+
+   o  The filing date of the application is a constructive date of
+      first use of the mark in commerce (this gives registrant
+      nationwide priority as of the date).
+
+   o  The right to sue in Federal court for trademark infringement.
+
+   o  Constructive notice of claim of ownership.
+
+   o  Limited grounds for attacking a registration once it is five
+      years old.
+
+4.8.  How to Apply for a Trademark with the PTO
+
+   You should obtain a trademark application and detailed instructions
+   from the U.S. Department of Commerce, Patent and Trademark Office.
+   This can be done by mailing your request to the address below, or
+   calling the PTO at the phone number below:
+
+                       U.S. Department of Commerce
+                       Patent and Trademark Office
+                       Washington, D.C.   20231
+                       Phone:  (703) 557-INFO
+
+   NOTE:  The following information is based on ESnet experience in
+          filing for a trademark based on prior use.
+
+   After you receive your application, you will need to perform the
+   following steps.
+
+   1.  Complete the written application form.  If you have more than
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 38]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+       one name you are filing, you must complete a separate form for
+       each name.
+
+   2.  Provide a black-and-white drawing of the mark.  In the case
+       where there is no artwork, only text, the text must be
+       centered on the page in uppercase.
+
+   3.  Provide a check in the amount of $175 (for each application)
+       made payable to the Commissioner of Patents and Trademarks.
+
+   4.  Provide three specimens showing actual use of the mark on or
+       in connection with the goods or services.
+
+   The class of goods/services associated with this trademark must be
+   specified on the registration form.  The currently defined classes of
+   services are:
+
+                     35  Advertising and business.
+                     36  Insurance and financial.
+                     37  Construction and repair.
+                     38  Communication.
+                     39  Transportation and storage.
+                     40  Material treatment.
+                     41  Education and entertainment.
+                     42  Miscellaneous.
+
+   So, for example, there could be two (or more) "ESnet" trademarks,
+   with each trademark associated with a different service class.  Thus,
+   trademarks are not nationally unique.
+
+   Before submitting your form, you should see if your trademark is
+   already registered to someone else (for the service class you
+   specified).  This is typically done by your legal department through
+   the PTO Trademark Search Library.
+
+   Since the PTO form is a legal document, you must involve your legal
+   department and the documents may only be signed by someone who is a
+   legally recognized representative of your organization.  For example,
+   in applying for the service mark "ESnet", the "Applicant Name" was
+   "The Regents of the University of California", and the legally
+   recognized representative was Dr. John Nuckolls, the director of the
+   Lawrence Livermore National Laboratory.
+
+4.9.  Future Name Registration Issues to be Considered
+
+4.9.1.  ANSI Registered ADMD and PRMD Names
+
+   There are discussions in the ANSI and CCITT communities revolving
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 39]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   around the idea of having a formal registration of all ADMD and PRMD
+   Names (not just ANSI Organization Names).  The ideas being exchanged
+   include having a separate ANSI national registry for these names, and
+   having to pay a periodic "license" fee.  This is just in the idea
+   discussion phase now, but it may impact the cost of ANSI ADMD and
+   PRMD Name registration in the near future.
+
+Glossary
+
+AA - See ADMINISTRATIVE AUTHORITY.
+
+ADDMD - See ADMINISTRATIVE DIRECTORY MANAGEMENT DOMAIN.
+
+ADMD - See ADMINISTRATION MANAGEMENT DOMAIN.
+
+ADMINISTRATION - An Administration denotes a public telecommunications
+     administration or other organization offering public
+     telecommunications services.
+
+ADMINISTRATION MANAGEMENT DOMAIN - An Administrative Management Domain
+     (ADMD) is a management domain managed by an Administration;
+     generally one of the common carriers (e.g. AT&T, MCI, U.S. Sprint,
+     etc.).
+
+ADMINISTRATIVE AUTHORITY - An entity which has administrative control
+     over all entries stored within a single Directory System Agent
+     (DSA).
+
+ADMINISTRATIVE DIRECTORY MANAGEMENT DOMAIN - An Administrative Directory
+     Management Domain (ADDMD) is a Directory Management Domain (DMD)
+     which is managed by an administration.
+
+AE - See APPLICATION ENTITY.
+
+ALIAS - An entry of the class "alias" containing information used to
+     provide an alternative name for an object.
+
+ANSI - The American National Standards Institute.  ANSI is the official
+     representative of the United States to ISO.
+
+AP - See APPLICATION PROCESS.
+
+APPLICATION ENTITY - An application entity is the OSI portion of an
+     Application Process (AP).
+
+APPLICATION LAYER - The application layer is the portion of an OSI
+     system ultimately responsible for managing communication between
+     application processes (APs).
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 40]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+APPLICATION PROCESS - An application process is an object executing in a
+     real system (computer).
+
+APPLICATION SERVICE ELEMENT - An application service element (ASE) is
+     the building block of an application entity (AE).  Each AE consists
+     of one or more service elements, as defined by its application
+     context.
+
+ASE - See APPLICATION SERVICE ELEMENT.
+
+ATTRIBUTE - An attribute is the information of a particular type
+     concerning an object and appearing in an entry describing that
+     object in the Directory Information base (DIB).
+
+ATTRIBUTE TYPE - An attribute type is that component of an attribute
+     which indicates the class of information given by that attribute.
+
+ATTRIBUTE VALUE - An attribute value is a particular instance of the
+     class of information indicated by an attribute type.
+
+BASE ATTRIBUTE SET - A minimum set of attributes whose values
+     unambiguously identify a particular management domain.
+
+BODY - The body of the IP-message is the information the user wishes to
+     communicate.
+
+CCITT - An international standards making organization specializing in
+     international communications standards and chartered by the United
+     Nations.  "CCITT" is a french acronym meaning the International
+     Telephone and Telegraph Consultative Committee.
+
+CHAINING - Chaining is a mode of interaction optionally used by a
+     Directory System Agent (DSA) which cannot perform an operation
+     itself.  The DSA chains by invoking the operation of another DSA
+     and then relaying the outcome to the original requestor.
+
+CLNP - The OSI Connectionless Network Protocol.  CLNP's use is required
+     by GOSIP.
+
+CONTENT - The piece of information that the originating User Agent (UA)
+     wishes delivered to the recipient UA.  For inter-personal messaging
+     (IPM) UAs, the content consists of either an IP message or an IPM-
+     status-report.
+
+COOPERATING USER AGENT - A User Agent (UA) that cooperates with another
+     recipient's UA in order to facilitate the communication between
+     originator and recipient.
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 41]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+DAP - See DIRECTORY ACCESS PROTOCOL.
+
+DELIVERY - The interaction by which the Message Transfer Agent (MTA)
+     transfers to a recipient User Agent (UA) the content of a message
+     plus the delivery envelope.
+
+DELIVERY ENVELOPE - The envelope which contains the information related
+     to the delivery of the message.
+
+DESCRIPTIVE NAME - A name that denotes one and only one user in the
+     Message Handling System (MHS).
+
+DIB - See DIRECTORY INFORMATION BASE.
+
+DIRECTORY - The Directory is a repository of information about objects
+     and which provides directory services to its users which allow
+     access to the information.
+
+DIRECTORY ACCESS PROTOCOL - The Directory Access Protocol (DAP) is the
+     protocol used between a Directory user Agent (DUA) and a Directory
+     System Agent (DSA).
+
+DIRECTORY ENTRY - A Directory Entry is a part of the Directory
+     Information Base (DIB) which contains information about an object.
+
+DIRECTORY INFORMATION BASE - The Directory Information Base (DIB) is the
+     complete set of information to which the Directory provides access
+     and which includes all pieces of information which can be read or
+     manipulated using the operations of the Directory.
+
+DIRECTORY INFORMATION TREE - The Directory Information Tree (DIT) is the
+     Directory Information Base (DIB), considered as a tree, whose
+     vertices (other than the root) are the Directory entries.
+
+DIRECTORY MANAGEMENT DOMAIN - A Directory Management Domain (DMD) is a
+     collection of one or more Directory System Agents (DSAs) and zero
+     or more Directory User Agents (DUAs) which is managed by a single
+     organization.
+
+DIRECTORY SYSTEM AGENT - A Directory System Agent (DSA) is an OSI
+     application process which is part of the Directory.
+
+DIRECTORY SYSTEM PROTOCOL - The Directory System Protocol (DSP) is the
+     protocol used between two Directory System Agents (DSAs).
+
+DIRECTORY USER - A Directory user is the entity or person that accesses
+     the Directory.
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 42]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+DIRECTORY USER AGENT - A Directory User Agent (DUA) is an OSI
+     application process which represents the user in accessing the
+     Directory.
+
+DISTINGUISHED NAME - The distinguished name of a given object is the
+     sequence of relative distinguished names (RDNs) of an entry which
+     represents the object and those of all of its superior entries (in
+     descending order).
+
+DIT - See DIRECTORY INFORMATION TREE.
+
+DMD - See DIRECTORY MANAGEMENT DOMAIN.
+
+DN - See DISTINGUISHED NAME.
+
+DNS - See DOMAIN NAME SERVICE.
+
+DOMAIN NAME SERVICE - A hierarchical, distributed naming service
+     currently used in the Internet.  DNS names typically take the form
+     of <machine.site.domain>, where <.domain> may be ".COM", ".EDU",
+     ".GOV", ".MIL", ".NET", ".ORG" or ".<country-code>".
+
+DSA - See DIRECTORY SYSTEM AGENT.
+
+DSP - See DIRECTORY SYSTEM PROTOCOL.
+
+DUA - See DIRECTORY USER AGENT.
+
+ENCODED INFORMATION TYPE - It is the code and format of information that
+     appears in the body of an IP-message (examples of coded information
+     types are Telex, TIFO (Group 4 Facsimile), and voice).
+
+ENVELOPE - A place in which the information to be used in the
+     submission, delivery and relaying of a message is contained.
+
+FIPS - Federal Information Processing Standard.  FIPS are produced by
+     NIST and specify a standard for the federal government, most FIPS
+     reference other formal standards from ANSI, IEEE, ISO or CCITT.
+
+GOSIP - The Government Open System Interconnection (OSI) Profile.  GOSIP
+     is a FIPS which defines the elements of OSI to be required by
+     government purchasers and how those elements should be implemented.
+     GOSIP is based on OSI standards and OIW implementor's agreements.
+
+HEADING - The heading of an IP-message is the control information that
+     characterizes an IP-message.
+
+INTERPERSONAL MESSAGING - Interpersonal Messaging (IPM) is communication
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 43]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+     between persons by exchanging messages.
+
+INTERPERSONAL MESSAGING SERVICE - The set of service elements which
+     enable users to exchange interpersonal messages.
+
+INTERPERSONAL MESSAGING SYSTEM - An Interpersonal Messaging System
+     (IPMS) is the collection of User Agents (UAs) and Message Transfer
+     Agents (MTAs), which provide the Interpersonal Messaging Service.
+
+IP - A non-OSI network protocol, the Internet Protocol, used extensively
+     in the Internet.  CLNP is the OSI alternative to IP.
+
+IP-MESSAGE - An IP-message carries information generated by and
+     transferred between Interpersonal Messaging (IPM) User Agents
+     (UAs).  An IP-message contains a Heading and a Body.
+
+IPM - See INTERPERSONAL MESSAGING.
+
+IPM-STATUS-REPORT - The pieces of information generated by an
+     Interpersonal Messaging (IPM) User Agent Entity (UAE) and
+     transferred to another IPM UAE, either to be used by that UAE or to
+     be conveyed to the user.
+
+IPMS - See INTERPERSONAL MESSAGING SYSTEM.
+
+ISO - An international standards making organization which, among other
+     things, develops OSI standards.
+
+MANAGEMENT DOMAIN - The set of Message Handling System (MHS) entities
+     managed by an Administration or organization that includes at least
+     one Message Transfer Agent (MTA).
+
+MD - See MANAGEMENT DOMAIN.
+
+MESSAGE - In the context of Message Handling Systems (MHSs), the unit of
+     information transferred by the Message Transfer System (MTS).  It
+     consists of an envelope and a content.
+
+MESSAGE HANDLING ADDRESS - An Originator/Recipient (O/R) address which
+     is comprised of an Administrative Management Domain (ADMD), a
+     country name, and a set of user attributes.
+
+MESSAGE HANDLING SYSTEM - The set of User Agents (UAs) plus the Message
+     Transfer System (MTS).
+
+MESSAGE TRANSFER AGENT - The functional component that, together with
+     the other Message Transfer Agents (MTAs), constitutes the Message
+     Transfer System (MTS).  The MTAs provide message transfer service
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 44]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+     elements by:  (1) interacting with originating User Agents (UAs)
+     via the submission dialogue, (2) relaying messages to other MTAs
+     based upon recipient designations, and (3) interacting with
+     recipient UAs via the delivery dialogue.
+
+MESSAGE TRANSFER AGENT ENTITY - The Message Transfer Agent Entity (MTAE)
+     is an entity, located in an MTA, that is responsible for
+     controlling the Message Transfer Layer (MTL).  It controls the
+     operation of the protocol to other peer entities in the MTL.
+
+MESSAGE TRANSFER LAYER - The Message Transfer Layer (MTL) is a layer in
+     the Application layer that provides Message Transfer System (MTS)
+     service elements.  These services are provided by means of the
+     services of the layer below plus the functionality of the entities
+     in the layer, namely the Message Transfer Agent Entities (MTAEs)
+     and the Submission and Delivery Entities (SDEs).
+
+MESSAGE TRANSFER PROTOCOL - The Message Transfer Protocol (P1) is the
+     protocol which defines the relaying of messages between Message
+     Transfer Agents (MTAs) and other interactions necessary to provide
+     Message Transfer layer (MTL) services.
+
+MESSAGE TRANSFER SERVICE - The Message Transfer Service is the set of
+     optional service elements provided by the Message Transfer System
+     (MTS).
+
+MESSAGE TRANSFER SYSTEM - The Message Transfer System (MTS) is the
+     collection of Message Transfer Agents (MTAs), which provide the
+     Message Transfer Service elements.
+
+MHS - See MESSAGE HANDLING SYSTEM.
+
+MTA - See MESSAGE TRANSFER AGENT.
+
+MTAE - See MESSAGE TRANSFER AGENT ENTITY.
+
+MTL - See MESSAGE TRANSFER LAYER.
+
+MTS - See MESSAGE TRANSFER SYSTEM.
+
+MULTICASTING - Multicasting is a mode of interaction which may
+     optionally be used by a Directory System Agent (DSA) which cannot
+     perform an operation itself.  The DSA multicasts the operation
+     (i.e. it invokes the operation of several other DSAs (in series or
+     in parallel) and passes an appropriate outcome to the original
+     requestor).
+
+NAME - A name is a construct that singles out a particular object from
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 45]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+     all other objects.  A name must be unambiguous (i.e. denote just
+     one object); however, it need not be unique (i.e. be the only name
+     which unambiguously denotes the object).
+
+NIST - The national institute of standards, a government organization
+     which develops, endorses, and promulgates standards for use by the
+     U.S.  government.
+
+O/R ADDRESS - See ORIGINATOR/RECIPIENT ADDRESS.
+
+O/R NAME - See ORIGINATOR/RECIPIENT NAME.
+
+OBJECT (OF INTEREST) - Anything in some "world", generally the world of
+     telecommunications and information processing or some part thereof,
+     which is identifiable (i.e. can be named), and which it is of
+     interest to hold information on in the Directory Information Base
+     (DIB).
+
+OIW - The OSI Implementors workshop.  OIW is one of three regional
+     workshops (OIW, EWOS, AOW), which specifies implementation
+     agreements for base OSI standards.  OIW's participants are mostly
+     from the Americas and the OIW is jointly sponsored by the IEEE
+     (Institute of Electrical and Electronic Engineers) and NIST.
+
+OPEN SYSTEMS INTERCONNECTION - A term referring to the capability of
+     interconnecting different systems.
+
+ORIGINATING USER AGENT - The Originating User Agent (UA) is a UA that
+     submits to the Message Transfer System (MTS) a message to be
+     transferred.
+
+ORIGINATOR - A user, a human being or computer process, from whom the
+     Message Handling System (MHS) accepts a message.
+
+ORIGINATOR/RECIPIENT ADDRESS - A descriptive name for a User Agent (UA)
+     that contains certain characteristics which help the Message
+     Transfer System (MTS) to locate the UA's point of attachment.  An
+     Originator/Recipient (O/R) address is a type of O/R name.
+
+ORIGINATOR/RECIPIENT NAME - The Originator/Recipient Name (O/R Name) is
+     the descriptive name for a User Agent (UA).
+
+OSI - See OPEN SYSTEMS INTERCONNECTION.
+
+PRDMD - See PRIVATE DIRECTORY MANAGEMENT DOMAIN.
+
+PRIMITIVE NAME - A name assigned by a naming authority.  Primitive names
+     are components of descriptive names.
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 46]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+PRIVATE DIRECTORY MANAGEMENT DOMAIN - A Private Directory Management
+     Domain (PRDMD) is a Directory Management Domain which is managed by
+     an organization other than an administration.
+
+PRIVATE MANAGEMENT DOMAIN - A Private Management Domain (PRMD) is a
+     management domain managed by a company or non-commercial
+     organization.
+
+PRMD - See PRIVATE MANAGEMENT DOMAIN.
+
+RDN - See RELATIVE DISTINGUISHED NAME.
+
+RECIPIENT - A user, a human being or computer process, who receives a
+     message from the Message Handling System (MHS).
+
+RECIPIENT USER AGENT - A User Agent (UA) to which a message is delivered
+     or that is specified for delivery.
+
+REFERRAL - A referral is an outcome which can be returned by a Directory
+     System Agent (DSA) which cannot perform an operation itself, and
+     which identifies one or more other DSAs more able to perform the
+     operation.
+
+RELATIVE DISTINGUISHED NAME - A Relative Distinguished Name (RDN) is a
+     set of attribute value assertions, each of which is true,
+     concerning the distinguished values of a particular entry.
+
+RELAYING - The interaction by which one Message Transfer Agent (MTA)
+     transfers to another MTA the content of a message plus the relaying
+     envelope.
+
+RELAYING ENVELOPE - The envelope which contains the information related
+     to the operation of the Message Transfer System (MTS) plus the
+     service elements requested by the originating User Agent (UA).
+
+RFC - Request for Comments.  The RFC's are documents used to propose or
+     specify internet community standards.
+
+ROOT - The vertex that is not the final vertex of any arc is referred to
+     as the root vertex (or informally as the root) of the tree.
+
+SCHEMA - The Directory Schema is the set of rules and constraints
+     concerning the Directory Information Tree (DIT) structure, object
+     class definitions, attribute types, and syntaxes which characterize
+     the Directory Information base (DIB).
+
+SDE - See SUBMISSION AND DELIVERY ENTITY.
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 47]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+SMTP - Simple Mail Transfer Protocol.  An e-mail protocol frequently
+     used by the Internet community.
+
+SUBMISSION - The interaction by which an originating User Agent (UA)
+     transfers to a Message Transfer Agent (MTA) the contents of a
+     message plus the submission envelope.
+
+SUBMISSION AND DELIVERY ENTITY - The Submission and Delivery Entity
+     (SDE) is an entity located in the Message Transfer Layer (MTL),
+     co-resident with a User Agent (UA) and not with a Message Transfer
+     Agent (MTA), and responsible for controlling the submission and
+     delivery interactions with a Message Transfer Agent Entity (MTAE).
+
+SUBMISSION AND DELIVERY PROTOCOL - The Submission and Delivery Protocol
+     (P3) is the protocol which governs communication between a
+     Submission and Delivery Entity (SDE) and a Message Transfer Agent
+     Entity (MTAE).
+
+SUBMISSION ENVELOPE - The envelope which contains the information the
+     Message Transfer System (MTS) requires to provide the requested
+     service elements.
+
+TCP - A non-OSI transport protocol, the Transmission Control Protocol,
+     used extensively in the Internet.  TP4 is the OSI alternative to
+     TCP.
+
+TP0 - An OSI transport protocol specified by GOSIP and generally used
+     with connection-oriented networks.
+
+TP4 - An OSI transport protocol specified by GOSIP and generally used
+     with connectionless networks such as CLNP.
+
+TREE - A tree is a set of points (vertices), and a set of directed lines
+     (arcs); each arc leads from a vertex V to a vertex V'.  The
+     vertices V and V' are said to be the initial and final vertices of
+     an arc a from V to V'.  In a tree, several different arcs may have
+     the same initial vertex, but not the same final vertex.
+
+UA - See USER AGENT.
+
+UAE - See USER AGENT ENTITY.
+
+UAL - See USER AGENT LAYER.
+
+USER - A person or computer application or process who makes use of a
+     Message Handling System (MHS).
+
+USER AGENT - Typically, the User Agent (UA) is a set of computer
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 48]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+     processes (for example, an editor, a file system, a word processor)
+     that are used to create, inspect, and manage the storage of
+     messages.  There is typically one user per User Agent (UA).  During
+     message preparation, the originator communicates with his UA via an
+     input/output (I/O) device (for example, a keyboard, display,
+     printer, facsimile machine, and/or telephone).  Also by means of
+     these devices, the UA communicates to its user messages received
+     from the Message Transfer System (MTS).  To send and receive
+     messages, the UA interacts with the MTS via the submission and
+     delivery protocol.
+
+USER AGENT ENTITY - A User Agent Entity (UAE) is an entity in the User
+     Agent Layer (UAL) of the Application Layer that controls the
+     protocol associated with cooperating UAL services.  It exchanges
+     control information with the Message Transfer Agent Entity (MTAE)
+     or the Submission and Delivery Entity (SDE) in the layer below.
+     The control information is the information the Message Transfer
+     layer (MTL) requires to create the appropriate envelope and thus
+     provide the desired message transfer service elements.
+
+USER AGENT LAYER - The User Agent Layer (UAL) is the layer that contains
+     the User Agent Entities (UAEs).
+
+X.25 - A packet switched network standard often used by public providers
+     and optional in GOSIP.
+
+Appendix A:  Current Activities in X.500
+
+   NOTE:  The following are edited excerpts from the IETF Directory
+   Services Monthly reports as well as a few IETF scope documents.
+   Effort has been taken to make sure this information is current as of
+   late 1991.  At the end of each section are lists of anonymous FTP
+   and/or an e-mail address if more information is desired.
+
+                                 IETF DISI
+       (Directory Information Services Infrastructure Working Group)
+
+   The Directory Information Services (pilot) Infrastructure Working
+   Group is chartered to facilitate the deployment in the Internet of
+   Directory Services based on implementations of the X.500 standards.
+   It will facilitate this deployment by producing informational RFCs
+   intended to serve as a Directory Services "Administrator's Guide".
+   These RFCs will relate the current usage and scope of the X.500
+   standard and Directory Services in North America and the world, and
+   will contain information on the procurement, installation, and
+   operation of various implementations of the X.500 standard.  As the
+   various implementations of the X.500 standard work equally well over
+   TCP/IP and CLNP, the DISI working group shall not mandate specific
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 49]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   implementations or transport protocols.
+
+   DISI is an offshoot of the OSI Directory Services group, and,
+   accordingly, is a combined effort of the OSI Integration Area and
+   User Services Area of the IETF.  The current OSIDS working group was
+   chartered to smooth out technical differences in information storage
+   schema and difficulties in the interoperability and coherence of
+   various X.500 implementations.  The DISI group is concerned solely
+   with expanding the Directory Services infrastructure.  As DISI will
+   be providing information to facilitate the building of infrastructure
+   with an eye towards truly operational status, DISI will need to form
+   liaisons with COSINE, PARADISE, and perhaps the RARE WG3.
+
+   As a final document, the DISI working group shall write a charter for
+   a new working group concerned with user services, integration,
+   maintenance and operations of Directory Services, the Operations and
+   Infrastructure of Directory Services (OIDS) Group.
+
+   One particular DISI document you may be interested in is a catalogue
+   of the various X.500 implementations:
+
+      Title     : Catalog of Available X.500 Implementations
+      Author(s) : R. Lang, R. Wright
+      Filename  : rfc1292.txt
+      Pages     : 103
+
+   This document is available on the ESnet Information Server in the
+   [ANONYMOUS.RFCS] directory.
+
+   Mailing list address:
+      General Discussion:  disi@merit.edu
+      To Subscribe:        disi-request@merit.edu
+   Anonymous FTP site address:  (e-mail archive is here)
+      merit.edu
+
+             IETF OSI-DS (OSI Directory Service Working Group)
+
+   The OSI-DS group works on issues relating to building an OSI
+   Directory Service using X.500 and its deployment on the Internet.
+   Whilst this group is not directly concerned with piloting, the focus
+   is practical, and technical work needed as a pre-requisite to
+   deployment of an open Directory will be considered.
+
+   The major goal of this WG is to provide the technical framework for a
+   Directory Service infrastructure on the Internet.  This
+   infrastructure should be based on the OSI Directory (X.500).  It is
+   intended that this infrastructure can be used by many applications.
+   Whilst this WG is not directly concerned with operation of services,
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 50]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   close liaison is expected with those groups which do operate pilots
+   and services.
+
+   Liaisons have been established with RARE WG3, NIST, CCITT/ISO IEC,
+   North American Directory Forum.
+
+   X.500 (1984) / ISO 9594 does not have sufficient functionality for
+   full deployment on the Internet.  This group identifies areas where
+   extensions are required.
+
+   It is a basic aim of the group to be aligned to appropriate base
+   standards and functional standards.  Any activity should be
+   undertaken in the light of ongoing standardization activity.  Areas
+   which should be examined include:
+
+   o  Replication
+
+   o  Knowledge Representation
+
+   o  Schema Management
+
+   o  Access Control
+
+   o  Authentication
+
+   o  Distributed operations for partially connected DSAs
+
+   o  Presentation Address Handling
+
+   Mailing list address:
+      General Discussion:  osi-ds@cs.ucl.ac.uk
+      To Subscribe:        osi-ds-request@cs.ucl.ac.uk
+   Anonymous FTP site address:  (all OSI-DS documents and e-mail archive
+      cs.ucl.ac.uk               are here)
+
+                   FOX (Field Operational X.500 Project)
+
+   The FOX project is a DARPA funded effort to provide a basis for
+   operational X.500 deployment in the NREN/Internet.  This work is
+   being carried out at Merit, NYSERnet/PSI, SRI and ISI.  ISI is the
+   main contractor and responsible for project oversight.
+
+   There are two primary thrusts of the FOX project:
+
+   1.  X.500 Infrastructure:  It is important that multiple
+       interoperable platforms be available for deployment.  FOX
+       plans to examine and test the interoperability of the QUIPU
+       and NIST-X.500 (Custos) implementations, and DNANS-X.500 if
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 51]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+       possible.  In addition, FOX will explore X.500 interfaces to
+       conventional database systems (one target is Sybase), an
+       alternate OS platform (VM) for X.500 servers, and X-window
+       based user interfaces.
+
+   2.  X.500 Applications:  A long-range goal is to facilitate the
+       use of X.500 for real Internet applications.  FOX will first
+       focus on making network infrastructure information available
+       through X.500.  This includes network and AS site contacts,
+       topology information, and the NIC WHOIS service.
+
+   A centrally managed X.500 version will be the first phase of a WHOIS
+   service.  Providing an X.500 version of a well-known widely-used
+   service should promote the use of X.500 by Internet users.  In
+   addition, this effort will provide experience in designing X.500
+   applications.  However, the manageability of this scheme will be
+   short-lived, so the next step will be a design for a distributed
+   version of WHOIS.
+
+   Finally, it is critical for Internet X.500 efforts to be aligned with
+   directory service efforts that are ongoing in other communities.  FOX
+   participants are involved in, or are otherwise tracking these
+   efforts, and information about FOX activities will be publicly
+   available.
+
+                   NADF (North American Directory Forum)
+
+   The North American Directory Forum (NADF) is a collection of
+   organizations which offer, or plan to offer, public Directory
+   services in North America, based on the CCITT X.500 Recommendations.
+
+   The NADF has produced a document, NADF-175, "A Naming Scheme for
+   c=US", which has been issued as RFC-1255.
+
+   The NADF-175 document proposes the use of existing civil
+   infrastructure for naming objects under c=US.  This has the advantage
+   of using existing registration authorities and not establishing any
+   new ones (the document simply maps names assigned by existing
+   authorities into different portions of the c=US DIT).  The document
+   is intended as the basis for X.500 names in the U.S. for the long-
+   term; it is important that interested parties get a copy, review it,
+   and return comments.
+
+   A second output, which is still undergoing development, is NADF-128,
+   a preliminary draft on "Mapping the DIT onto Multiple ADDMDs".  This
+   describes how the c=US portion of the DIT is mapped onto DSAs and
+   what service-providers must minimally share in order to achieve a
+   working public directory.  The next revision of this document will
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 52]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   likely be ASCII-ized and published as an informational RFC.
+
+           NIST (National Institute of Standards and Technology)
+
+   NIST is involved in several X.500 activities:  standards, pilot
+   deployment, and development of an X.500 implementation, Custos.  The
+   objective is to see X.500 widely deployed and used in the U.S.
+   Government.  X.500 is expected to be in the next release of the U.S.
+   Government OSI Profile (GOSIP).  In the standards efforts, emphasis
+   is on access control and replication; the other activities are
+   described in some detail below.
+
+   o  NIST/GSA X.500 Pilot Deployment:  NIST and GSA are
+      collaborating in the creation of a U.S. Government X.500 pilot
+      deployment.  To date, two meetings have been held.  At the
+      second, held on April 25th at NIST, significant progress was
+      made towards refining an initial draft schema developed by
+      NIST.  A number of government agency requirements will be
+      included in the next schema revision.  Once the schema is
+      defined, agencies will begin collecting data for loading into
+      the directory.  Initially, NIST will offer to host agency data
+      on Custos DSAs running at NIST.  Eventually, agencies are
+      expected to obtain and operate DSAs.
+
+   o  CUSTOS:  The NIST X.500 public-domain implementation, Custos,
+      is implemented on ISODE, although it otherwise bears no
+      relation to QUIPU.  One of its more interesting features is that
+      the DBMS interface is SQL, and we provide a simple DBMS as part
+      of Custos to support the DSA.  Information can be optionally
+      loaded into memory, and the memory usage is reasonably
+      efficient on a per-entry basis.
+
+                     OIW (OSI Implementor's Workshop)
+
+   The OSI Implementor's Workshop (OIW) is an open public forum for
+   technical issues, concerned with the timely development of
+   implementation agreements based on emerging international OSI
+   standards.  The Workshop accepts as input the specifications of
+   emerging standards for protocols, and produces as output agreements
+   on the implementation and testing particulars of these protocols.
+   This process is expected to expedite the development of OSI protocols
+   and to promote interoperability of independently manufactured data
+   communications equipment.
+
+   The Workshop organizes its work through Special Interest Groups
+   (SIGs) that prepare technical documentation.  The SIGs are encouraged
+   to coordinate with standards organizations and user groups, and to
+   seek widespread technical consensus on implementation agreements
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 53]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   through international discussions and liaison activities.
+
+   The Directory SIG of the Workshop produces agreements on the
+   implementation of Directory protocols based on ISO 9594 and CCITT
+   X.500 Recommendations.  There are three major areas that the SIG is
+   working on for 1991:  access control, replication, and distributed
+   operations.
+
+   Mailing list address:
+      General Discussion:  dssig@nisc.sri.com
+      To Subscribe:        dssig-request@nisc.sri.com
+
+                             PARADISE Project
+
+   The PARADISE project is based at the Department of Computer Science,
+   University College London (UCL).
+
+   PARADISE is a sub-project of the broader COSINE project sponsored
+   under the umbrella of EUREKA by eighteen participating countries and
+   aimed at promoting OSI to the academic, industrial and governmental
+   research and development organizations in Europe.  The countries
+   involved are those of the EC, EFTA plus Yugoslavia; that is:
+   Austria, Belgium, Denmark, Finland, France, Germany, Greece, Holland,
+   Ireland, Italy, Luxembourg, Norway, Portugal, Spain, Sweden,
+   Switzerland, United Kingdom, and Yugoslavia.
+
+   The partners funded by PARADISE besides UCL are:
+
+   o  The Networks Group at the University of London Computer Centre
+      (ULCC), which is a service-oriented organization providing a
+      range of facilities to the academic community in London and the
+      entry point into the UK for IXI, the COSINE international X.25
+      backbone;
+
+   o  X-Tel Services Ltd, a software company based in Nottingham
+      which currently provides service support to the UK Academic
+      X.500 pilot; and
+
+   o  PTT Telematic Systems from the Netherlands, which in turn has
+      subcontracted the Swiss and Finnish PTTs, and whose involvement
+      is to create a forum for discussion on X.500 among the European
+      carrier administrations.
+
+   The project also aims to have representation from all the
+   participating countries, which in the majority of cases are the
+   existing X.500 national pilots.
+
+   Of the 18 countries involved, at least 12 are registered in the White
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 54]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   Pages Pilot Project.  Most countries are using the QUIPU
+   implementation developed at UCL.  However, a French group has
+   developed PIZARRO, which will form the basis of the emerging French
+   pilot.  In Italy, a Torino-based company Systems Wizards are using
+   DirWiz, which is currently the sole representative from Italy in the
+   tree.
+
+   Mailing list address:
+      helpdesk@paradise.ulcc.ac.uk
+
+                       PSI White Pages Pilot Project
+
+   The White Pages Pilot Project is the first production-quality field
+   test of the OSI Directory (X.500).  The pilot currently has a few
+   hundred organizations (more each month) and is based on OSI TP4 over
+   TCP/IP (RFC-1006).
+
+   Anonymous FTP site address:  (Most X.500 pilot project software is
+      uu.psi.com                 here as well as more information)
+
+                 ANSI ASC X3T5.4 (Directory Ad Hoc Group)
+
+   The American National Standards Institute (ANSI) Accredited Standards
+   Committee (ASC) X3T5.4.  This group reviews the Proposed Draft
+   Amendments (PDAMs) for extensions to the International Consultative
+   Committee for Telegraphy and Telephony (CCITT) X.500
+   Recommendations/International Organization for Standardization
+   (ISO)/International Electrotechnical Commission (IEC) 9594.
+
+Appendix B:  Current Activities in X.400
+
+   NOTE:  The following are edited excerpts from the IETF X.400 Services
+   Monthly reports as well as a few IETF scope documents.  Effort has
+   been taken to make sure this information is current as of February
+   1992.  At the end of each section are lists of anonymous FTP and/or
+   an e-mail address if more information is desired.
+
+                IETF OSIX400 (IETF OSI X.400 Working Group)
+
+   The IETF OSI X.400 Working Group is chartered to identify and provide
+   solutions for problems encountered when operating X.400 in a dual
+   protocol internet.  This charter includes pure X.400 operational
+   issues as well as X.400 <-> RFC 822 gateway (ala RFC 987) issues.
+
+   Mailing list address:
+      General Discussion:  ietf-osi-x400@cs.wisc.edu
+      To Subscribe:        ietf-osi-x400-request@cs.wisc.edu
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 55]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+            IETF X400OPS (IETF X.400 Operations Working Group)
+
+   X.400 management domains are being deployed today on the Internet.
+   There is a need for coordination of the various efforts to insure
+   that they can interoperate and collectively provide an Internet-wide
+   X.400 message transfer service connected to the existing Internet
+   mail service.  The overall goal of this group is to insure
+   interoperability between Internet X.400 management domains and to the
+   existing Internet mail service.  The specific task of this group is
+   to produce a document that specifies the requirements and conventions
+   of operational Internet PRMDs.
+
+   Mailing list address:
+      General Discussion:  ietf-osi-x400ops@pilot.cs.wisc.edu
+      To Subscribe:        ietf-osi-x400ops-request@pilot.cs.wisc.edu
+
+     IETF MHS-DS (IETF Message Handling Services - Directory Services)
+
+   The MHS-DS Group works on issues relating to Message Handling Service
+   use of Directory Services.  The Message Handling Services are
+   primarily X.400, but issues relating to RFC 822 and RFC 822
+   interworking, in as far as use of the Directory is concerned, are in
+   the scope of the Group.  Directory Services means the services based
+   on X.500 as specified by the OSI-DS group (RFCs 1274, 1275, 1276,
+   1277, 1278, 1297).  The major aim of this group is to define a set of
+   specifications to enable effective large scale deployment of X.400.
+   While this Group is not directly concerned with piloting, the focus
+   is practical, and implementations of this work by members of the
+   Group is expected.
+
+   Mailing list address:
+      General Discussion:  mhs-ds@mercury.udev.cdc.com
+      To Subscribe:        mhs-ds-request@mercury.udev.cdc.com
+   Anonymous FTP site address:  (e-mail archive is here)
+      mercury.udev.cdc.com
+
+                         XNREN X.400 Pilot Project
+
+   The Internet X.400 Project at the University of Wisconsin is funded
+   by NSF.  We are working on two main areas:
+
+   1.  Supporting the operational use of X.400.
+
+   2.  Working with others to define organizational procedures
+       necessary to operate X.400 on a large scale in the Internet.
+
+   To support the use of X.400, we are operating a PRMD, assisting sites
+   in running PP or the Wisconsin Argo X.400 software packages, and
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 56]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   running an X.400 Message Transfer Agent (MTA) which is connected to
+   U.S. and international MTAs using RFC1006/TCP/IP.  Internet sites are
+   invited to join our PRMD or establish X.400 connections with us.  The
+   organizational work is being done jointly by IETF working groups and
+   RARE Working Group 1.
+
+   Mailing list address:
+      General Discussion:  x400-project-team@cs.wisc.edu
+
+        RARE WG1 (RARE Working Group 1 - Message Handling Systems)
+
+   RARE (Reseaux Associes pour la Recherche Europeenne) Working Group 1,
+   Message Handling Systems, creates and promotes a European
+   infrastructure for a message handling service within the European
+   research community, with connections to the global environment.
+   Membership of the Working Group is by nomination from the national
+   networking organizations, together with a number of invited experts.
+
+      CCITT SG-D MHS-MD (CCITT Study Group D, MHS Management Domains)
+
+   This group initially pursues the  development of  the  rules for
+   registering MHS management Domain names within the US.  This group
+   also pursues developing  a set of voluntary agreements for North
+   American operators of these management  domains  which  will  allow
+   the  US  to uphold  its Telecommunications   treaty   obligations
+   while   the industry maintains  e-mail  as  an  Information
+   Processing  service.  The specific  aspect  of the treaty that is
+   immediate concern to this group is that subscribers of MHS  services
+   in  other  countries, especially  those countries who treat MHS as a
+   Telecommunications service, must  be  able  to reach  MHS  users  in
+   this  country regardless  of  how their message enters the US and
+   regardless of how many domains are involved in the transfer of the
+   message  to the intended recipient.
+
+   The US State Department presently considers MHS  (e-mail)  as  an
+   Information  Processing  service.  Some other countries consider any
+   MHS (e-mail) service  to  be  a Telecommunications  service  and
+   hence, CCITT treaty obligations apply.
+
+              NIST/GSA Interagency X.400 Connectivity Project
+
+   The goal of this project is to assist the members of the Federal
+   Information Resource Management Policy Council (FIRMPoC) in
+   establishing electronic mail connectivity based on X.400.  The
+   outcome of this project is to continue, as the National Institute of
+   Standards and Technology (NIST) has done in the past, providing
+   Federal agencies with assistance in establishing electronic mail
+   connectivity.  This project is sponsored by the General Services
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 57]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   Administration (GSA).
+
+Appendix C:  How to Obtain QUIPU, PP and ISODE
+
+                              ISODE/QUIPU 7.0
+
+   This software supports the development of certain kinds of OSI
+   protocols and applications.  Here are the details:
+
+   o  The ISODE is not proprietary, but it is not in the public
+      domain.  This was necessary to include a "hold harmless"
+      clause in the release.  The upshot of all this is that anyone
+      can get a copy of the release and do anything they want with
+      it, but no one takes any responsibility whatsoever for any
+      (mis)use.
+
+   o  The ISODE runs on native Berkeley (4.2, 4.3) and AT&T System V
+      systems, in addition to various other UNIX-like operating
+      systems.  No kernel modifications are required.
+
+   o  Current modules include:
+
+      -  OSI transport service (TP0 on top of TCP, X.25 and CONS;
+         TP4 for SunLink OSI)
+
+      -  OSI session, presentation, and association control services
+
+      -  ASN.1 abstract syntax/transfer notation tools, including:
+
+         1.  Remote operations stub-generator (front-end for remote
+             operations)
+
+         2.  Structure-generator (ASN.1 to C)
+
+         3.  Element-parser (basic encoding rules)
+
+      -  OSI reliable transfer and remote operations services
+
+      -  OSI directory services
+
+      -  OSI file transfer, access and management
+
+      -  FTAM/FTP gateway
+
+      -  OSI virtual terminal (basic class, TELNET profile)
+
+   o  ISODE 7.0 consists of final "IS" level implementations with the
+      exception of VT which is a DIS implementation.  The ISODE also
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 58]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+      contains implementations of the 1984 X.400 versions of ROS and
+      RTS.
+
+   o  Although the ISODE is not "supported" per se, it does have a
+      problem reporting address, Bug-ISODE@XTEL.CO.UK.  Bug reports
+      (and fixes) are welcome by the way.
+
+   o  The discussion group ISODE@NISC.SRI.COM is used as an open
+      forum on ISODE.  Contact ISODE-Request@NISC.SRI.COM to be added
+      to this list.
+
+   o  The primary documentation for this release consists of a five
+      volume User's Manual (approx. 1000 pages) and a set of UNIX
+      manual pages.  The sources to the User's Manual are in LaTeX
+      format.  In addition, there are a number of notes, papers, and
+      presentations included in the documentation set, again in
+      either LaTeX or SLiTeX format.  If you do not have LaTeX, you
+      should probably get a hardcopy from one of the distribution
+      sites below.
+
+                      ISODE/QUIPU Distribution Sites
+
+   The FTP or FTAM distributions of ISODE-7.0 consists of 3 files.  The
+   source and main ISODE-7.0 distribution is in the file ISODE-7.tar.Z
+   which is approximately 4.7MB in size.
+
+   LaTeX source for the entire document set can be found in the ISODE-
+   7-doc.tar.Z file (3.5MB).  A list of documents can be found in the
+   doc/ directory of the source tree.
+
+   A Postscript version of the five volume manual can be found in the
+   ISODE-7-ps.tar.Z file (4.3MB).
+
+   If you can FTP to the Internet, then use anonymous FTP to uu.psi.com
+   [136.161.128.3] to retrieve the files in BINARY mode from the ISODE/
+   directory.
+
+                 Additional PSI White Pages Pilot Software
+
+   The 'usconfig' program configures a DSA which understands some of the
+   NADF naming rules.  This software is primarily intended for creating
+   directory hierarchies for DSAs from scratch.  The add-on software is
+   available via anonymous FTP from uu.psi.com in:
+
+      wp/src/wpp-addon.tar.Z
+
+   Whether you choose to use 'usconfig' or not, please retrieve and
+   install the addon, and follow the instructions therein. You might
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 59]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   want to retrieve pilot-ps.tar.Z again also, as it contains an updated
+   Administrator Guide.
+
+   Note that the wpp-addon.tar.Z file needs to be installed on top of
+   the ISODE 7.0 distribution; it does not duplicate any of the ISODE
+   7.0, you need to retrieve and generate that too.
+
+                                  PP 6.0
+
+   PP is a Message Transfer Agent, intended for high volume message
+   switching, protocol conversion, and format conversion.  It is
+   targeted for use in an operational environment, but is also be useful
+   for investigating message related applications.  Good management
+   features are a major aspect of this system.  PP supports the 1984 and
+   1988 versions of the CCITT X.400 / ISO 10021 services and protocols.
+   Many existing RFC-822 based protocols are supported, along with RFC-
+   1148bis conversion to X.400.  PP is an appropriate replacement for
+   MMDF or Sendmail.  This is the second public release of PP, and
+   includes substantial changes based on feedback from using PP on many
+   sites.
+
+   o  PP is not proprietary and can be used for any purpose.  The only
+      restriction is that suing of the authors for any damage the
+      code may cause is not allowed.
+
+   o  PP runs on a range of UNIX and UNIX-like operating systems,
+      including SUNOS, Ultrix, and BSD.  A full list of platforms on
+      which PP is know to run is included in the distribution.
+
+   o  Current modules include:
+
+      -  X.400 (1984) P1 protocol.
+
+      -  X.400 (1988) P1 protocol.
+
+      -  Simple mail transfer protocol (SMTP), conformant to host
+         requirements.
+
+      -  JNT mail (grey book) Protocol.
+
+      -  UUCP mail transfer.
+
+      -  DECNET Mail-11 transfer
+
+      -  Distribution list expansion and maintenance, using either a
+         file based mechanism or an X.500 directory.
+
+      -  RFC 822-based local delivery.
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 60]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+      -  Delivery time processing of messages.
+
+      -  Conversion between X.400 and RFC-822 according to the latest
+         revision of RFC-1148, known as RFC-1148bis.
+
+      -  Conversion support for reformatting body parts and headers.
+
+      -  X-Window and line-based management console.
+
+      -  Message Authorization checking.
+
+      -  Reformatting support for "mail hub" operation.
+
+      -  X.500-based distribution list facility using the QUIPU
+         directory.
+
+      -  FAX interworking
+
+   o  No User Agents (UAs) are included with PP.  However, procedural
+      access to the MTA is documented, to encourage others to write
+      or to port UAs.  Several existing UAs, such as MH, may be used
+      with PP.
+
+   o  It is expected that a Message Store to be used in conjunction
+      with PP (PPMS), and an associated X-Windows User Agent (XUA)
+      will be released on beta test in first quarter 92.
+
+   o  The core routing of PP 6.0 is table based.  DNS is used by the
+      SMTP channel.  The next version of PP will support Directory
+      Based routing, which may use X.500 or DNS.
+
+   o  PP 6.0 requires ISODE 7.0.
+
+   o  X-Windows release X11R4 (or greater) is needed by some of the
+      management tools.  PP can be operated without these tools.
+
+   o  Although PP is not "supported" per se (but see later), it does
+      have a problem reporting address (bug reports (and fixes) are
+      welcome):
+
+      RFC-822:  PP-SUPPORT@CS.UCL.AC.UK
+      X.400:    S=PP-Support; OU=CS; O=UCL;
+                PRMD=UK.AC; ADMD= ; C=GB;
+
+   o  The discussion group PP-PEOPLE@CS.UCL.AC.UK is used as an open
+      forum on PP; Contact PP-PEOPLE-REQUEST@CS.UCL.AC.UK to be added
+      to this list.
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 61]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   o  The primary documentation for this release consists of a three
+      and a half volume User's Manual (approx. 300 pages) and a set
+      of UNIX manual pages.  The sources to the User's Manual are in
+      LaTeX format.
+
+                           PP Distribution Sites
+
+   If you can FTP to the Internet from outside Europe, then use
+   anonymous FTP to uu.psi.com [136.161.128.3] to retrieve the file pp-
+   6.tar.Z in binary mode from the ISODE/ directory.  This file is the
+   tar image after being run through the compress program and is
+   approximately 3Mb in size.
+
+   If you can FTP to the Internet from Europe, then use anonymous FTP to
+   archive.eu.net [192.16.202.1] to retrieve the file pp-6.tar.Z in
+   binary mode from the network/ISODE/ directory.  This file is the tar
+   image after being run through the compress program and is
+   approximately 3Mb in size.
+
+             ISODE/QUIPU and PP Platforms as of December 1991
+
+   Machine          OS                       ISODE  PP   Stacks  Notes
+   ====================================================================
+   CCUR 6000        RTU 5.0                  7.0    Yes! TCP     1
+   --------------------------------------------------------------------
+   CCUR 6000        RTU 6.0                  7.0    Yes! TCP     2
+                                                         X25
+                                                         CLNS
+   --------------------------------------------------------------------
+   CDC 4000 Series  EP/IX 1.3.2              6.6+        TCP     3
+                    EP/IX 1.4.1                          CLNS
+                                                         X25
+   --------------------------------------------------------------------
+   COMPAQ 386/25    SCO Unix 5.2             6.0         TCP
+   --------------------------------------------------------------------
+   COMPAQ 386       BSD                      7.0         TCP     4
+                                                         X25
+   --------------------------------------------------------------------
+   Convex C120      ConvexOS 8.1             7.0         TCP     5
+   --------------------------------------------------------------------
+   DEC Vax          2nd Berkeley Network rel 7.0         TCP
+                                                         X25
+   --------------------------------------------------------------------
+   DEC              DECnet-ULTRIX V5.0       7.0         TCP     6
+                                                         CLNS
+   --------------------------------------------------------------------
+   DEC              Ultrix 3.1D              7.0    5.2  TCP     7
+                    Ultrix 4.0                           X25
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 62]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+                    Ultrix 4.1
+   --------------------------------------------------------------------
+   DEC              Ultrix 4.2               7.0        TCP
+                                                        X25
+                                                        CLNS
+   --------------------------------------------------------------------
+   DEC              VMS v5.x                 7.0        TCP
+                                                        X25
+   --------------------------------------------------------------------
+   DG Avion         DGUX 4.30                7.0        TCP      8
+   --------------------------------------------------------------------
+   Encore Multimax 3xx UMAX V 2.2h           6.0        TCP      9
+   Encore Multimax 5xx
+   --------------------------------------------------------------------
+   Encore NP1       UTX/32 3.1a              7.0        TCP      10
+                                                        X25
+   --------------------------------------------------------------------
+   Encore PN6000    UTX/32 2.1b              6.0        TCP      9
+   Encore PN9000                                        X25
+   --------------------------------------------------------------------
+   HP/9000/3xx      HP/UX 6.0                7.0        TCP      11
+                    HP-UX 7.05 B
+   --------------------------------------------------------------------
+   HP/9000/8xx      HP-UX 7.00               7.0        TCP      11
+                                                        X25
+   --------------------------------------------------------------------
+   IBM 3090         AIX/370 1.2.1            7.0        TCP      12
+   --------------------------------------------------------------------
+   IBM PS/2         AIX 1.2.1                6.7        TCP      13
+   --------------------------------------------------------------------
+   IBM RS/6000      AIX 3.1                  6.8        TCP
+                    AIX 3.0
+   --------------------------------------------------------------------
+   ICL              DRS/6000                 7.0    5.2 TCP      14
+   --------------------------------------------------------------------
+   Macintosh        A/UX 2.0.1               7.0        TCP
+   --------------------------------------------------------------------
+   Macintosh        MacOS V6.x               6.0        TCP      15
+   --------------------------------------------------------------------
+   Mips 4-52        ATT-V3-0                 7.0    5.2 TCP      16
+   --------------------------------------------------------------------
+   NeXT                                      7.0    5.2 TCP      17
+   --------------------------------------------------------------------
+   ORION/Clipper                             6.8        TCP
+   --------------------------------------------------------------------
+   Olivetti LSX-3020 X/OS 2.1                6.7b   5.0 TCP      1
+                                                        X25
+   --------------------------------------------------------------------
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 63]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   Pyramid 9800     OSx 5.1 (4.3BSD/SVR3.2)  7.0    5.2 TCP      18
+   Pyramid MIS
+   --------------------------------------------------------------------
+   SEQUENT          DYNIX V3.0.18            7.0        TCP      8
+   --------------------------------------------------------------------
+   Sony News-1750   NEWS-OS 3.3              6.8        TCP
+                    NEWS-OS 4.0c
+   --------------------------------------------------------------------
+   Sun4             SunOS 4.1                7.0    5.2 TCP
+   Sun3             SunOS 4.1.1                         X25
+                    SunOS 4.0.3c                        CONS
+                                                        CLNS
+   --------------------------------------------------------------------
+
+   Notes:
+
+   1.  NOT SNMP or VT
+
+   2.  Little tested
+
+   3.  Official upper layer
+
+   4.  Prototype only!
+
+   5.  Planned port
+
+   6.  Being worked on!
+
+   7.  3.1D binaries compiled under 4.2
+
+   8.  Only QUIPU confirmed
+
+   9.  Not QUIPU
+
+   10.  Need "-Dregister=" in CONFIG.make
+
+   11.  Need bug-fix no. 5 from bug-ISODE@xtel.co.uk. not SNMP,VT or
+        FTAM-FTP gateway
+
+   12.  No VT, QUIPU not tested
+
+   13.  Models 80 and 95
+
+   14.  NOT SNMP or VT,PP and X.25 requires patches available from
+        X-Tel
+
+   15.  Using MacTCP
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 64]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   16.  Only QUIPU tested, built using BSD43 config
+
+   17.  Need bug-fix no. 6 from bug-ISODE@xtel.co.uk
+
+   18.  Built using BSD config, no VT or SNMP
+
+   The above tables do not refer to beta releases of ISODE  and PP more
+   recent than the public ISODE-7.0 or PP-5.2 releases.  The above table
+   is generated from reports sent to bug-ISODE and pp-support.  There is
+   no guarantee the information is correct.
+
+Appendix D:  Sample X.500 Input File and Restricted Character List
+
+   Below is a sample datafile that illustrates the format for providing
+   data about persons at your site to be loaded into the ESnet DSA.
+   Following the sample datafile is a detailed explanation of the format
+   and content of the file.  We have tried to be as flexible as possible
+   in defining the format of the file, given the constraints imposed by
+   an automated process.  We would appreciate feedback on the format of
+   the file and will try to accommodate any specific needs you may have
+   to any extent that is reasonable.
+
+   #
+   #        Sample Data File for Bulk Loading X.500 Database
+   #
+   # delimiter character is ","                                        1
+   # field 1 is commonName                                             2
+   # field 2 is phone extension                                        3
+   #   area code for all numbers is 510                                4
+   #   prefix for all numbers is 422                                   5
+   # field 3 is rfc822Mailbox                                          6
+   # field 4 is facsimileTelephoneNumber                               7
+   # default facsimileTelephoneNumber is (510) 422-3333                8
+   # postalAddress for all entries is:                                 9
+   #     National Energy Research Supercomputer Center                10
+   #     P.O. Box 5509                                                11
+   #     Livermore, California 94552                                  12
+   #
+   Chris Anderson,1915,anderson@ws1.nersc.gov,                        13
+   Lila Brown,5680,brownl@ws2.nersc.gov,                              14
+   Bob Green,4474,,                                                   15
+   Max Jones,4488,elvis@presley.nersc.gov,5104224444                  16
+   Dave Smith,9818,smithd@ws3.nersc.gov,                              17
+   Cathy White,4016,snow@white.nersc.gov,                             18
+   <end-of-file>
+
+   Comment lines at the beginning of the file convey relevant formatting
+   information.
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 65]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   Following comment lines, each data line contains information about
+   one person.
+
+   Fields within a single data line are separated by a delimiter
+   character.  You specify the delimiter character you wish to use in
+   the comment section; be sure to choose a delimiter which does not
+   appear as a legitimate character in any field of a data line.
+
+   You may provide all or part of the attribute types listed in the
+   table in Section 2.5 (commonName is required).  In the comment
+   section, you must indicate which attribute types are contained in
+   each field of a data line.
+
+   Each data line must contain the same number of fields and the same
+   order of fields (i.e. same order of attribute types).  Two successive
+   delimiters indicated a null value (eof is a considered a field
+   delimiter).
+
+   The characters "=", "&", "$", and "#" are NEVER allowed in any
+   attribute value.
+
+   Below is a discussion of relevant lines of the sample datafile.
+
+   Line 1      The delimiter character is identified as a comma (,).
+
+   Line 2      Field # 1 is identified as containing the commonName
+                 attribute.
+
+   Line 3      Field # 2 is identified as containing the telephoneNumber
+                 attribute.  The actual data value is a 4-digit
+                 extension.
+
+   Lines 4,5   Identify the area code and prefix which apply to all
+                 4-digit extensions in the datafile.  If your actual
+                 data values already contain area code and/or prefix,
+                 then there would be no need to indicate default values.
+
+   Line 6      Field # 3 is identified as containing the rfc822Mailbox
+                 attribute.
+
+   Line 7      Field # 4 is identified as containing the
+                 facsimileTelephoneNumber attribute.
+
+   Line 8      Identifies the default value for
+                 facsimileTelephoneNumber.  If field 4 is missing in a
+                 data line, the default value will be applied.
+
+   Lines 9-12  Identify the value of the postalAddress attribute which
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 66]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+                 applies to all entries.
+
+   Line 13  commonName= Chris Anderson
+            surName= Anderson
+            telephoneNumber= 510-422-1915
+            rfc822MailBox= anderson@ws1.nersc.gov
+            facsimileTelephoneNumber= 510-422-3333
+            postalAddress= National Energy Research Supercomputer Center
+                           P.O. Box 5509
+                           Livermore, California 94552
+
+   Line 14  commonName= Lila Brown
+            surName= Brown
+            telephoneNumber= 510-422-5680
+            rfc822MailBox= brownl@ws2.nersc.gov
+            facsimileTelephoneNumber= 510-422-3333
+            postalAddress= National Energy Research Supercomputer Center
+                           P.O. Box 5509
+                           Livermore, California 94552
+
+   Line 15  commonName= Bob Green
+            surName= Green
+            telephoneNumber= 510-422-4474
+            rfc822MailBox=
+            facsimileTelephoneNumber= 510-422-3333
+            postalAddress= National Energy Research Supercomputer Center
+                           P.O. Box 5509
+                           Livermore, California 94552
+
+   Line 16  commonName= Max Jones
+            surName= Jones
+            telephoneNumber= 510-422-4488
+            rfc822MailBox= elvis@presley.nersc.gov
+            facsimileTelephoneNumber= 510-422-4444
+            postalAddress= National Energy Research Supercomputer Center
+                           P.O. Box 5509
+                           Livermore, California 94552
+
+   Line 17  commonName= Dave Smith
+            surName= Smith
+            telephoneNumber= 510-422-9818
+            rfc822MailBox= smithd@ws3.nersc.gov
+            facsimileTelephoneNumber= 510-422-3333
+            postalAddress= National Energy Research Supercomputer Center
+                           P.O. Box 5509
+                           Livermore, California 94552
+
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 67]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   Line 18  commonName= Cathy White
+            surName= White
+            telephoneNumber= 510-422-4016
+            rfc822MailBox= snow@white.nersc.gov
+            facsimileTelephoneNumber= 510-422-3333
+            postalAddress= National Energy Research Supercomputer Center
+                           P.O. Box 5509
+                           Livermore, California 94552
+
+Appendix E:  ESnet Backbone Sites
+
+                            Government Agencies
+
+   U.S. Department of Energy, Office of Energy Research (DOE)
+   Germantown, Maryland   USA
+
+   U.S. Department of Energy, San Francisco Office (SAN)
+   Oakland, California   USA
+
+                           National Laboratories
+
+   NASA Ames Research Center (AMES, FIX-WEST)
+   Mountain View, California   USA
+
+   Argonne National Laboratory (ANL)
+   Argonne, Illinois   USA
+
+   Brookhaven National Laboratory (BNL)
+   Upton, New York   USA
+
+   Continuous Electron Beam Accelerator Facility (CEBAF)
+   Newport News, Virginia   USA
+
+   Fermi National Accelerator Laboratory (FNAL)
+   Batavia, Illinois   USA
+
+   Lawrence Berkeley Laboratory (LBL)
+   Berkeley, California   USA
+
+   Lawrence Livermore National Laboratory (LLNL)
+   Livermore, California   USA
+
+   Los Alamos National Laboratory (LANL)
+   Los Alamos, New Mexico   USA
+
+   Oak Ridge National Laboratory (ORNL)
+   Oak Ridge, Tennessee   USA
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 68]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   Pacific Northwest Laboratory (PNL)
+   Richland, Washington   USA
+
+   Princeton Plasma Physics Laboratory (PPPL)
+   Princeton, New Jersey   USA
+
+   Sandia National Laboratory, Albuquerque (SNLA)
+   Albuquerque, New Mexico   USA
+
+   Stanford Linear Accelerator Center (SLAC)
+   Menlo Park, California   USA
+
+   Superconducting Super Collider (SSC)
+   Dallas, Texas   USA
+
+                               Universities
+
+   California Institute of Technology (CIT)
+   Pasadena, California   USA
+
+   Florida State University (FSU)
+   Tallahassee, Florida   USA
+
+   Iowa State University (ISU)
+   Ames, Iowa   USA
+
+   Massachusetts Institute of Technology (MIT)
+   Cambridge, Massachusetts   USA
+
+   New York University (NYU)
+   Upton, New York   USA
+
+   Oak Ridge Associated Universities (ORAU)
+   Oak Ridge, Tennessee   USA
+
+   University of California, Los Angeles (UCLA)
+   Westwood, California   USA
+
+   University of Maryland (UMD, FIX-EAST)
+   College Park, Maryland   USA
+
+   University of Texas, Austin (UTA)
+   Austin, Texas   USA
+
+                            Commercial Entities
+
+   General Atomics (GA)
+   San Diego, California   USA
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 69]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   Office of Science and Technology Information (OSTI)
+   Oak Ridge, Tennessee   USA
+
+   Science Applications, Incorporated (SAIC)
+   McLean, Virginia   USA
+
+Appendix F:  Local Site Contacts for DOE Naming Authorities
+
+   Below is a list of all Department of Energy GOSIP Site Authorities
+   for OSI registration and addressing.  This information was obtained
+   from the DoE GOSIP On-Line Information System (DOE-GOIS), dated
+   November 18, 1991.
+
+   Marian F. Sotel
+   Director, Information management Division
+   U.S. Department of Energy
+   DOE Field Office, Albuquerque
+
+   Dennis Jensen
+   Ames Laboratory
+   258H Development
+   Ames, IA 50011-3020
+   (515) 294-7909
+
+   Linda Winkler
+   Argonne National Laboratory
+   Argonne, IL 60439
+   (708) 972-7236
+
+   R. E. Kremer
+   Manager, Resource Automation
+   U.S. Department of Energy
+   Bettis Atomic Power laboratory
+
+   Gary Ragsdale
+   Manager, Information Services
+   U.S. Department of Energy
+   Bonneville Power Administration
+   905 NE 11th Avenue
+   Portland, OR 97232
+
+   Wayne Larson
+   Head of Data Communications Unit
+   U.S. Department of Energy
+   Bonneville Power Administration
+   905 NE 11th Avenue
+   Portland, OR 97232
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 70]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   George Rabinowitz
+   Head Distributed Computing Section
+   Brookhaven National Laboratory
+   Upton, New York 11973
+   (516) 282-7637
+
+   Donna A. Dyxin
+   Communications Specialist
+   U.S. Department of Energy
+   DOE Field Office, Chicago
+   9800 South Cass Avenue
+   Argonne, IL 60439
+
+   Elaine R. Liebrecht
+   System Manager and Planning Supervisor
+   EG&G Mound Applied Technologies
+   P.O. Box 3000
+   Miamisburg, OH 45343-3000
+   (FTS) 774-3733 or (513) 865-3733
+
+   Jeffrey J. Johnson
+   Communications Supervisor
+   EG&G Mound Applied Technologies
+   P.O. Box 3000
+   Miamisburg, OH 45343-3000
+   (FTS) 774-4230 or (513) 865-4230
+
+   Paul P. Herr
+   U.S. Department of Energy
+   Energy Information Agency
+   (202) 586-7318
+
+   William H. Foster
+   U.S. Department of Energy
+   Energy Information Agency
+   (202) 586-6310
+
+   Mark O. Kaletka
+   Data Communications Group Leader, Computing Div.
+   Fermi National Accelerator Lab
+   P.O. Box 500
+   Batavia, IL 60510
+   (708) 840-2965
+
+   David A. Mackler
+   Grand Junction Project Office
+   (FTS) 326-6412
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 71]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   Wayne L. Selfors
+   Grand Junction Project Office
+   (FTS) 326-6525
+
+   Gerald F. Chappell
+   Director, ITSO
+   U.S. Department of Energy
+   Headquarters
+   Washington D.C., 20545
+   (FTS) 233-3685 or (301) 903-3685
+
+   Joe Diel
+   Supervisor, Biomathematics Group
+   ITRI
+
+   David H. Robinson
+   Section Supervisor, Information Systems
+   Allied-Signal Aerospace Company
+   Kansas City Division
+   P.O. Box 419159
+   Kansas City, MO 64141-6159
+   (FTS) 997-3690 or (816) 997-3690
+
+   Robert M. Jensen
+   Supervisory Engineer, Information Systems
+   Allied-Signal Aerospace Company
+   Kansas City Division
+   P.O. Box 419159
+   Kansas City, MO 64141-6159
+   (FTS) 997-5538 or (816) 997-5538
+
+   Russell Wright
+   Lawrence Berkeley Laboratories
+   1 Cyclotron Road
+   Berkeley, CA 94720
+   (510) 486-6965
+
+   William A. Lokke
+   Associate Director for Computation
+   Lawrence Livermore National Lab
+   (FTS) 532-9870 or (669) 422-9870
+
+   Philip Wood/Glenn Michel
+   Los Alamos National Laboratory
+   Los Alamos, NM 87545
+   (FTS) 843-1845 or (FTS) 843-2598
+
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 72]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   Robert Bruen
+   MIT Laboratory for Nuclear Science
+   Computer Facilities Manager
+   Massachusetts Institute of Tech.
+   Cambridge, MA
+
+   Mark Cerullo
+   Morgantown Energy Technology Center
+   (FTS) 923-4345
+
+   Hank Latham
+   NVRSN
+   (FTS) 575-7646
+
+   Bill Morrison
+   Network Specialist
+   Bechtel Petroleum Operations, Inc
+   Naval Petroleum Reserves California
+   P.O. Box 127
+   Tupman, CA 93276
+   (FTS) 797-6933 or (805) 763-6933
+
+   Mary Ann Jones
+   DOE Field Office, Nevada
+
+   Bill Freberg
+   Computer Sciences Corporation
+   DOE Field Office, Nevada
+
+   Roger Hardwick
+   Project Director
+   Roy F. Weston
+   OCRWM
+   3885 S. Decatur Blvd.
+   Las Vegas, NV 89103
+   (702) 873-6200
+
+   John Gandi
+   U.S. Department of Energy
+   OCRWM
+   101 Convention Ctr
+   Phase II Complex, Suite 202
+   Las Vegas, NV 89109
+   (702) 794-7954
+
+   Benny Goodman
+   U.S. Department of Energy
+   OSTI
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 73]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   Raymond F. Cook
+   U.S. Department of Energy
+   OSTI
+
+   D. M. Turnpin
+   Martin Marietta Energy Systems, Inc
+   Oak Ridge
+   P.O. Box 2009
+   Oak Ridge, TN 37831-8227
+   (FTS) 626-8848 or (615) 576-8848
+
+   T. E. Birchfield
+   Supervisor, Electronic Informations Delivery Sect.
+   Martin Marietta Energy Systems, Inc
+   Oak Ridge
+   P.O. Box 2008
+   Oak Ridge, TN 37831-6283
+   (FTS) 624-4635 or (615) 574-4635
+
+   Bobby Brumley
+   TRESP Associates
+   DOE Field Office, Oak Ridge
+
+   Mike Letterman
+   TRESP Associates
+   DOE Field Office, Oak Ridge
+
+   S. Dean Carpenter
+   Department Head, Communications
+   Mason and Hanger
+   Pantex Plant
+
+   Wayne C. Phillips
+   Section Head, Internal Communications
+   Mason and Hanger
+   Pantex Plant
+
+   A. J. Lelekacs
+   Sr. Networking Engineer
+   General Electric
+   Pinellas Plant
+   P.O. Box 2908
+   Neutron Devices Department
+   Largo, FL 34649-2908
+
+
+
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 74]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   Paul A. Funk
+   Site Access Coordinator
+   Princeton Plasma Physics Laboratory
+   P.O. Box 451
+   Princeton, NJ 08543
+   (609) 243-3403
+
+   John Murphy
+   Branch Chief, Information and Communication Mgmt
+   U.S. Department of Energy
+   DOE Field Office, Richland
+   P.O. Box 550
+   Richland, WA 99352
+   (FTS) 444-7543 or (509) 376-7543
+
+   Mike Schmidt
+   Telecom & Network Services IRM
+   Westinghouse Hanford Company
+   DOE Field Office, Richland
+   P.O. Box 1970
+   Richland, WA 99352
+   (FTS) 444-7739 or (509) 376-7739
+
+   Dwayne Ramsey
+   Information Resources Management Division
+   U.S. Department of Energy
+   DOE Field Office, San Francisco
+   (FTS) 536-4302
+
+   W. F. Mason
+   Central Computing Systems Manager
+   Sandia National Laboratories - AL
+   P.O. Box 5800
+   Albuquerque, NM 87185
+   (FTS) 845-8059 or (505) 845-8059
+
+   Harry R. Holden
+   U.S. Department of Energy
+   DOE Field Office, Savannah River
+   P.O. Box A
+   Aiken, SC 29802
+   (FTS) 239-1118 or (803) 725-1118
+
+
+
+
+
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 75]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   Reggie Peagler
+   Network Security Officer
+   Savannah River Site
+   Building 773-51A
+   Aiken, SC 29808
+   (FTS) 239-3418 or (803) 557-3418
+
+   Wade A. Gaines
+   Acting ADP Manager
+   U.S. Department of Energy
+   Southeastern Power Administration
+   Samuel Elbert Building
+   Elberton, GA 30635
+
+   Paul Richard
+   Southwestern Power Administration
+   (FTS) 745-7482
+
+   Dr. R. Les Cottrell
+   Assistant Director, SLAC Computer Services
+   Stanford Linear Accelerator Center
+   P.O. Box 4349
+   Stanford, CA 94309
+
+   John Lucero
+   Systems Analyst, Management Systems
+   Westinghouse Electric Corporation
+   Waste Isolation Pilot Plant
+   P.O. Box 2078
+   Carlsbad, NM 88221
+   (FTS) 571-8459 or (505) 887-8459
+
+   Lawrence Bluhm
+   Sr. Systems Analyst, Management Systems
+   Westinghouse Electric Corporation
+   Waste Isolation Pilot Plant
+   P.O. Box 2078
+   Carlsbad, NM 88221
+   (FTS) 571-8459 or (505) 887-8459
+
+   Ben Sandoval
+   Western Area Power Administration
+   (FTS) 327-7470
+
+   John Sewell
+   Western Area Power Administration
+   (FTS) 327-7407
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 76]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+Appendix G:  Recommended Reading
+
+                        RFCs (Request For Comments)
+
+   The following RFCs may be obtained from the ESnet Information Server.
+   They are stored in the directory [ANONYMOUS.RFCS].  They may be
+   retrieved via anonymous FTP (nic.es.net, 128.55.32.3) or DECnet copy
+   (ESNIC::, 41.174).
+
+RFC1328  X.400 1988 to 1984 downgrading.  Hardcastle-Kille, S.E.  1992
+     May; 5 p. (Format: TXT=10006 bytes)
+
+RFC1327  Mapping Between X.400 (1988) /ISO 10021 and RFC 822.
+     Hardcastle-Kille, S.E.  1992 May; 113 p. (Format: TXT=228598 bytes)
+
+RFC1309  Technical overview of directory services using the X.500
+     protocol.  Weider, C.; Reynolds, J.K.; Heker, S.  1992 March; 4 p.
+     (Format: TXT=35694 bytes)
+
+RFC1308  Executive Introduction to Directory Services Using the X.500
+     Protocol.  Weider, C.; Reynolds, J.K.  1992 March; 4 p. (Format:
+     TXT=9392 bytes)
+
+RFC1295  North American Directory Forum.  User bill of rights for
+     entries and listing in the public directory.  1992 January; 2 p.
+     (Format: TXT=3502 bytes)
+
+RFC1292  Lang, R.; Wright, R.  Catalog of Available X.500
+     Implementations. 1991 December; 103 p. (Format: TXT=129468 bytes)
+
+RFC1279  Hardcastle-Kille, S.E.  X.500 and domains.  1991 November; 13
+     p. (Format: TXT=26669, PS=170029 bytes)
+
+RFC1278  Hardcastle-Kille, S.E.  String encoding of presentation
+     address. 1991 November; 5 p. (Format: TXT=10256, PS=128696 bytes)
+
+RFC1277  Hardcastle-Kille, S.E.  Encoding network addresses to support
+     operations over non-OSI lower layers.  1991 November; 10 p.
+     (Format: TXT=22254, PS=176169 bytes)
+
+RFC1276  Hardcastle-Kille, S.E.  Replication and distributed operations
+     extensions to provide an Internet directory using X.500. 1991
+     November; 17 p. (Format: TXT=33731, PS=217170 bytes)
+
+RFC1275  Hardcastle-Kille, S.E.  Replication requirements to provide an
+     Internet directory using X.500.  1991 November; 2 p. (Format:
+     TXT=4616, PS=83736 bytes)
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 77]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+RFC1274  Kille, S.E.; Barker, P.  COSINE and Internet X.500 schema. 1991
+     November; 60 p. (Format: TXT=92827 bytes)
+
+RFC1255  North American Directory Forum.  Naming scheme for c=US. 1991
+     September; 25 p. (Format: TXT=53783 bytes)  (Obsoletes RFC 1218)
+
+RFC1249  Howes, T.; Smith, M.; Beecher, B.  DIXIE protocol
+     specification.  1991 August; 10 p. (Format: TXT=20693 bytes)
+
+RFC1202  Rose, M.T.  Directory Assistance service.  1991 February; 11 p.
+     (Format: TXT=21645 bytes)
+
+RFC1006  Rose, M.T.; Cass, D.E.  ISO transport services on top of the
+     TCP: Version 3.  1987 May; 17 p. (Format: TXT=31935 bytes)
+
+                         Non Published Working Notes
+
+"A String Representation of Distinguished Names", S.E. Hardcastle-Kille,
+     01/30/1992.
+
+     The OSI Directory uses distinguished names as the primary keys to
+     entries in the directory.  Distinguished Names are encoded in
+     ASN.1. When a distinguished name is communicated between to users
+     not using a directory protocol (e.g., in a mail message), there is
+     a need to have a user-oriented string representation of
+     distinguished name.
+
+"An Access Control Approach for Searching and Listing", S.E.
+     Hardcastle-Kille, T. Howes, 09/23/1991.
+
+     This memo defines an extended ACL (Access Control List) mechanism
+     for the OSI Directory.  It is intended to meet strong operational
+     requirements to restrict searching and listing externally, while
+     allowing much more freedom within an organization.  In particular,
+     this mechanism makes it possible to restrict searches to certain
+     sets of attributes, and to prevent "trawling": the disclosure of
+     large organizational data or structure information by repeated
+     searches or lists. This capability is necessary for organizations
+     that want to hide their internal structure, or to prevent dumping
+     of their entire database.  This memo describes functionality
+     beyond, but compatible with, that expected in the 1992 X.500
+     standard.
+
+"Building an Internet Directory using X.500", S. Kille, 01/07/1991.
+
+     The IETF has established a Working Group on OSI Directory Services.
+     A major component of the initial work of this group is to establish
+     a technical framework for establishing a Directory Service on the
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 78]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+     Internet, making use of the X.500 protocols and services.  This
+     document summarizes the strategy established by the Working Group,
+     and describes a number of RFCs which will be written in order to
+     establish the technical framework.
+
+"Directory Requirements for COSINE and Internet Pilots (OSI-DS 18)",
+     S.E. Hardcastle-Kille, 07/09/1991.
+
+     This document specifies operational requirements for DUAs and DSAs
+     in the Internet and COSINE communities.  This document summarizes
+     conformance requirements.  In most cases, technical detail is
+     handled by reference to other documents.  This document refers to
+     core directory infrastructure. Each application using the directory
+     may impose additional requirements.
+
+"DSA Naming", S.E. Hardcastle-Kille, 01/24/1992.
+
+     This document describes a few problems with DSA Naming as currently
+     deployed in pilot exercises, and suggests a new approach.  This
+     approach is suggested for use in the Internet Directory Pilot,
+     which overcomes a number of existing problems, and is an important
+     component for the next stage in increase of scale.
+
+"Handling QOS (Quality of service) in the Directory", S.E. Kille,
+     08/29/1991.
+
+     This document describes a mechanism for specifying the Quality of
+     Service for DSA Operations and Data in the Internet Pilot Directory
+     Service "Building and internet directory using X.500".
+
+"Interim Directory Tree Structure for Network Infrastructure
+     Information", Chris Weider, Mark Knopper, Ruth Lang, 06/14/1991.
+
+     As work progresses on incorporating WHOIS and Network
+     Infrastructure information into X.500, we thought it would be
+     useful to document the current DIT structure for this information,
+     along with some thoughts on future expansion and organization of
+     this subtree of the DIT. The first section of this document
+     describes the current structure, the second section the possible
+     expansion of the structure.
+
+"Interim Schema for Network Infrastructure Information in X.500 New
+     name:  Encoding Network Addresses to support operation ov", Chris
+     Weider, Mark Knopper, 06/14/1991.
+
+     As the OSI Directory progresses into an operational structure which
+     is being increasingly used as a primary resource for Directory
+     Information, it was perceived that having the Internet Site
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 79]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+     Contacts and some limited network information in the Directory
+     would be immediately useful and would also provide the preliminary
+     framework for some distributed NIC functions. This paper describes
+     the interim schema used to contain this information.
+
+"Naming Guidelines for Directory Pilots", P. Barker, S.E. Kille,
+     01/30/1992.
+
+     Deployment of a Directory will benefit from following certain
+     guidelines. This document defines a number of naming guidelines.
+     Alignment to these guidelines will be recommended for national
+     pilots.
+
+"OSI NSAP Address Format For Use In The Internet", R Colella, R Callon,
+     02/13/1991.
+
+     The Internet is moving towards a multi-protocol environment that
+     includes OSI. To support OSI, it is necessary to address network
+     layer entities and network service users.  The basic principles of
+     OSI Network Layer addressing and Network Service Access Points
+     (NSAPs) are defined in Addendum 2 to the OSI Network service
+     definition.  This document recommends a structure for the Domain
+     Specific Part of NSAP addresses for use in the Internet that is
+     consistent with these principles.
+
+"Representing Public Archives in the Directory", Wengyik Yeong,
+     12/04/1991.
+
+     The proliferation of publicly accessible archives in the Internet
+     has created an ever-widening gap between the fact of the existence
+     of such archives, and knowledge about the existence and contents of
+     these archives in the user community. Related to this problem is
+     the problem of also providing users with the necessary information
+     on the mechanisms available to retrieve such archives.  In order
+     for the Internet user community to better avail themselves of this
+     class of resources, there is a need for these gaps in knowledge to
+     be bridged.
+
+"Schema for Information Resource Description in X.500", Chris Weider,
+     06/14/1991.
+
+     The authors are interested in allowing distributed access and
+     updating for Information Resource Description information to users
+     of the Internet. This paper discusses the schema used to hold the
+     Information Resource Description information.  The new attributes
+     are taken from the US-MARC fields, and subfields, with the mapping
+     described in the text.
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 80]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+"Schema for NIC Profile Information in X.500", Chris Weider, Mark
+     Knopper, 06/14/1991.
+
+     The authors of this document, in conjunction with the chairs of the
+     IETF Network Information Services Infrastructure (NISI) group,
+     would like to implement a Directory of Network Information Centers,
+     or NICs.  This will enable NICs to find each other easily, will
+     allow users with access to a DSA to find out where NICs are, and
+     will in general facilitate the distribution of information about
+     the Internet and some of its infrastructure.  This document
+     proposes a set of standard schema for this information.
+
+"Using the OSI Directory to Achieve User Friendly Naming", S. Kille,
+     01/30/1992.
+
+     The OSI Directory has user friendly naming as a goal.  A simple
+     minded usage of the directory does not achieve this.  Two aspects
+     not achieved are:  1)  A user oriented notation  and  2)
+     Guessability. This proposal sets out some conventions for
+     representing names in a friendly manner, and shows how this can be
+     used to achieve really friendly naming.  This then leads to a
+     specification of a standard format for representing names, and to
+     procedures to resolve them. This leads to a specification which
+     allows directory names to be communicated between humans.  The
+     format in this specification is identical to that defined in the
+     reference of "A String Representation of Distinguished Name", and
+     it is intended that these specifications are compatible.
+
+"Requirements for X.400 Management Domains (MDs) Operating in the Global
+     Research and Development X.400 Service", R. Hagens, 11/12/1991.
+
+     This  document  specifies  a  set  of  minimal   operational
+     requirements that  must  be  implemented  by all Management Domains
+     (MDs) in the Global R&D X.400 Service.   This  document  defines
+     the  core  operational requirements; in some cases, technical
+     detail is handled  by  reference  to other documents.  The Global
+     R&D X.400 Service is defined as all organizations which meet the
+     requirements described in this document.
+
+"Routing Coordination for X.400 MHS Services within a
+     Multiprotocol/Multinetwork Environment", U. Eppenberger,
+     10/25/1992.
+
+     The X.400 addresses do start to appear on business cards. The
+     different MHS service providers are not well interconnected and
+     coordinated which makes it a very hard job for the MHS managers to
+     know where to route all the new addresses. A big number of X.400
+     implementations support different lower layer stacks. Taking into
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 81]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+     account the variety of existing large transport networks, there is
+     now the chance of implementing a worldwide message handling service
+     using the same electronic mail standard and therefore without the
+     need of gateways with service reduction and without the restriction
+     to a single common transport network. This document proposes how
+     messages can travel over different networks by using multi stack
+     MTAs as relays. Document formats and coordination procedures bridge
+     the gap until an X.500 directory service is ready to store the
+     needed connectivity and routing information.
+
+                      International Standards Documents
+
+International Consultative Committee for Telephone and Telegraph. Open
+     Systems Interconnection - The Directory. X.500 Series
+     Recommendations.  December, 1988.
+
+     (also published as)
+
+ISO/IEC. Information Technology - Open Systems Interconnection - The
+     Directory. International Standard 9594. 1989.
+
+International Consultative Committee for Telephone and Telegraph. Data
+     Communication Networks - Message Handling Systems. X.400 Series
+     Recommendations. Geneva 1985.
+
+International Consultative Committee for Telephone and Telegraph. Data
+     Communication Networks - Message Handling Systems. X.400 Series
+     Recommendations. Melbourne, 1988.
+
+                               NIST Documents
+         (National Institute of Standards and Technology Documents)
+
+   The following documents can be retrieved from the ESnet Information
+   Server in directory [ANONYMOUS.NIST].
+
+Government Open Systems Interconnection Profile (GOSIP) Version 1,
+     National Institute of Standards and Technology, Federal Information
+     Processing Standards Publication #146, August, 1988.
+
+Government Open Systems Interconnection Profile (GOSIP) Version 2,
+     National Institute of Standards and Technology, October, 1990.
+
+                                DOE Documents
+
+   The following documents prepared by the DOE GOSIP Migration Working
+   Group can be retrieved from the ESnet Information Server in directory
+   [ANONYMOUS.DOE-GOSIP].
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 82]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+U.S. Department of Energy. Government Open Systems Interconnection
+     Profile.  Transition Strategy. DOE GOSIP Document # GW-ST-008.
+     November, 1990.
+
+U.S. Department of Energy. Government Open Systems Interconnection
+     Profile.  Transition Plan. DOE GOSIP Document # GW_PN_005.
+     November, 1990.
+
+U.S. Department of Energy. Government Open Systems Interconnection
+     Profile.  Procedures and Guidelines. DOE GOSIP Document # GW-PR-
+     007. April, 1991.
+
+                             IETF Working Groups
+
+   Three IETF working groups, OSI X.400, OSI-DS and MHS-DS have been
+   working in in X.400 and X.500. Minutes of meetings, descriptions of
+   the working groups' charters and goals, information about mailing
+   lists, and other pertinent documents can be retrieved from the ESnet
+   Information Server in the directories [ANONYMOUS.IETF.OSIDS],
+   [ANONYMOUS.IETF.OSIX400] and [ANONYMOUS.IETF.MHSMS].
+
+                                  Others
+
+Marshall T. Rose, Julian P. Onions and Colin J. Robbins. The ISO
+     Development Environment: User's Manual, 1991.  ISODE Documentation
+     Set.
+
+Marshall T. Rose and Wengyik Yeong.  PSI White Pages Pilot Project:
+     Administrator's Guide, 1991.  ISODE Documentation Set.
+
+Marshall T. Rose.  The Open Book: A Practical Perspective on Open
+     Systems Interconnection. Prentice-hall, 1990. ISBN 0-13-643016-3.
+
+Marshall T. Rose.  The Little Black Book: Mail Bonding with OSI
+     Directory Services. Prentice-hall, 1991. ISBN 0-13-683219-5.
+
+Alan Turner and Paul Gjefle, Pacfic Northwest Laboratory.  Performance
+     Analysis of an OSI X.500 (QUIPU) Directory Service Implmentation.
+     1992. Available on nic.es.net in the directory [ANONYMOUS.ESNET-
+     DOC]QUIPU-PERF.PS
+
+Appendix H:  Task Force Member Information
+
+   Bob Aiken
+     U.S. Department of Energy, Office of Energy Research, Scientific
+     Computing Staff (now with National Science Foundation)
+     Email:  raiken@nsf.gov
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 83]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   Joe Carlson
+     Lawrence Livermore National Laboratory
+     Livermore, California USA
+     Email:  carlson@lll-winken.llnl.gov
+
+   Les Cottrell
+     Stanford Linear Accelerator Center
+     Menlo Park, California USA
+     Email:  cottrell@slacvm.slac.stanford.edu
+
+   Tim Doody
+     Fermi National Accelerator Laboratory
+     Batavia, Illinois USA
+     Email:  doody@fndcd.fnal.gov
+
+   Tony Genovese  (Contributing Author)
+     Lawrence Livermore National Laboratory
+     Livermore, California USA
+     Email:  genovese@es.net
+
+   Arlene Getchell  (Contributing Author)
+     Lawrence Livermore National Laboratory
+     Livermore, California USA
+     Email:  getchell@es.net
+
+   Charles Granieri
+     Stanford Linear Accelerator Center
+     Menlo Park, California USA
+     Email:  cxg@slacvm.slac.stanford.edu
+
+   Kipp Kippenhan  (Contributing Author)
+     Fermi National Accelerator Laboratory
+     Batavia, Illinois USA
+     Email:  kippenhan@fnal.fnal.gov
+
+   Connie Logg
+     Stanford Linear Accelerator Center
+     Menlo Park, California USA
+     Email:  cal@slacvm.slac.stanford.edu
+
+   Glenn Michel
+     Los Alamos National Laboratory
+     Los Alamos, New Mexico USA
+     Email:  gym@lanl.gov
+
+   Peter Mierswa
+     Digital Equipment Corporation USA
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 84]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   Jean-Noel Moyne
+     Lawrence Berkeley Laboratory
+     Berkeley, California USA
+     Email:  jnmoyne@lbl.gov
+
+   Kevin Oberman  (Contributing Author)
+     Lawrence Livermore National Laboratory
+     Livermore, California USA
+     Email:  oberman@icdc.llnl.gov
+
+   Dave Oran
+     Digital Equipment Corporation USA
+
+   Bob Segrest
+     Digital Equipment Corporation USA
+
+   Tim Streater
+     Stanford Linear Accelerator Center
+     Menlo Park, California USA
+     Email:  streater@slacvm.slac.stanford.edu
+
+   Allen Sturtevant  (Chair, Contributing Author, Document Editor)
+     Lawrence Livermore National Laboratory
+     Livermore, California USA
+     Email:  sturtevant@es.net
+
+   Mike Sullenberger
+     Stanford Linear Accelerator Center
+     Menlo Park, California USA
+     Email:  mls@scsw5.slac.stanford.edu
+
+   Alan Turner  (Contributing Author)
+     Pacific Northwest Laboratory
+     Richland, Washington USA
+     Email:  ae_turner@pnl.gov
+
+   Linda Winkler  (Contributing Author)
+     Argonne National Laboratory
+     Argonne, Illinois USA
+     Email:  b32357@anlvm.ctd.anl.gov
+
+   Russ Wright  (Contributing Author)
+     Lawrence Berkeley Laboratory
+     Berkeley, California USA
+     Email:  wright@lbl.gov
+
+
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 85]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+Security Considerations
+
+   Security issues are discussed in sections 2.5.1 and 2.7.5.1 of this
+   memo.
+
+Authors' Addresses
+
+   Allen Sturtevant
+   Lawrence Livermore National Laboratory
+   P.O. Box 5509; L-561
+   Livermore, CA 94551
+
+   Phone:  +1 510-422-8266
+   Email:  sturtevant@es.net
+
+
+   Tony Genovese
+   Lawrence Livermore National Laboratory
+   P.O. Box 5509; L-561
+   Livermore, CA 94551
+
+   Phone:  +1 510-423-2471
+   Email:  genovese@es.net
+
+
+   Arlene Getchell
+   Lawrence Livermore National Laboratory
+   P.O. Box 5509; L-561
+   Livermore, CA 94551
+
+   Phone:  +1 510-423-6349
+   Email:  getchell@es.net
+
+
+   H. A. Kippenhan Jr.
+   Fermi National Accelerator Laboratory
+   Wilson Hall 6W, MS-234
+   P.O. Box 500
+   Batavia, IL 60150
+
+   Phone:  +1 708-840-8068
+   Email:  kippenhan@fnal.fnal.gov
+
+
+
+
+
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 86]
+
+RFC 1330            X.500 and X.400 Plans for ESnet             May 1992
+
+
+   Kevin Oberman
+   Lawrence Livermore National Laboratory
+   P.O. Box 5509; L-156
+   Livermore, CA 94551
+
+   Phone:  +1 510-422-6955
+   Email:  oberman1@llnl.gov
+
+
+   Alan Turner
+   Pacific Northwest Laboratory
+   P.O. Box 999; K7-57
+   Richland, WA 99352
+
+   Phone:  +1 509-375-6670
+   Email:  ae_turner@pnl.gov
+
+
+   Linda Winkler
+   Argonne National Laboratory
+   9700 South Cass Avenue
+   Building 221 B251
+   Argonne, IL 60439
+
+   Phone:  +1 708-252-7236
+   Email:  lwinkler@anl.gov
+
+
+   Russ Wright
+   Lawrence Berkeley Laboratory
+   1 Cyclotron Road
+   MS 50B-2258
+   Berkeley, CA 94720
+
+   Phone:  +1 510-486-6965
+   Email:  wright@lbl.gov
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ESCC X.500/X.400 Task Force                                    [Page 87]
+
\ No newline at end of file