GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1330

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:
  1. OSI transport service (TP0 on top of TCP, X.25 and CONS;

TP4 for SunLink OSI)

  1. OSI session, presentation, and association control services
  1. 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)
  1. OSI reliable transfer and remote operations services
  1. OSI directory services
  1. OSI file transfer, access and management
  1. FTAM/FTP gateway
  1. 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:
  1. X.400 (1984) P1 protocol.
  1. X.400 (1988) P1 protocol.
  1. Simple mail transfer protocol (SMTP), conformant to host

requirements.

  1. JNT mail (grey book) Protocol.
  1. UUCP mail transfer.
  1. DECNET Mail-11 transfer
  1. Distribution list expansion and maintenance, using either a

file based mechanism or an X.500 directory.

  1. 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

  1. Delivery time processing of messages.
  1. Conversion between X.400 and RFC-822 according to the latest

revision of RFC-1148, known as RFC-1148bis.

  1. Conversion support for reformatting body parts and headers.
  1. X-Window and line-based management console.
  1. Message Authorization checking.
  1. Reformatting support for "mail hub" operation.
  1. X.500-based distribution list facility using the QUIPU

directory.

  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1330.txt · Last modified: 1992/05/22 01:17 (external edit)