As per Relevance of the word registration, we have this rfc below:
Network Working Group ESCC X.500/X.400 Task
Request for Comments: 1330 ESnet Site Coordinating Committee (ESCC
Energy Sciences Network (ESnet
May 1992
Recommendations for the Phase I Deployment
OSI Directory Services (X.500)
OSI Message Handling Services (X.400)
within the ESnet
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
The Energy Sciences Network (ESnet) is a nation-wide computer
communications network managed and funded by the United
Department of Energy, Office of Energy Research (U.S. DOE/OER),
the purpose of supporting multiple program, open scientific research
ESnet is intended to facilitate remote access to major
Research (ER) scientific facilities, provide needed
dissemination among scientific collaborators throughout all
programs, and provide widespread access to existing ER
facilities
Coordination of ER-wide network-related technical activities over
ESnet backbone is achieved through the ESnet Site
Committee (ESCC). This committee is comprised of one
contact person from each backbone site, as well as some members
the ESnet management and networking staff. As the need for
levels of ESnet services arise, the ESCC typically creates
forces to investigate and research issues relating to these
services. Each task force usually results in a whitepaper
makes recommendations to the ESnet community on how these
should be deployed to meet the mission of DOE/OER
This RFC is a near verbatim copy of the whitepaper produced by
ESnet Site Coordinating Committee's X.500/X.400 Task Force
Table of
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= 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
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
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
OSI Directory Services (X.500)
OSI Message Handling Services (X.400)
within the ESnet
ESnet Site Coordinating Committee X.500/X.400 Task
Version 1.1
March 1992
Status of this
This document makes recommendations for the Phase I deployment of
Directory Services and OSI Message Handling Services within the
Community. This document is available via anonymous FTP on the
Information Server (nic.es.net, 128.55.32.3) in the
[ANONYMOUS.ESNET-DOC] in the file ESNET-X500-X400-VERSION-1-1.TXT
The distribution of this document is unlimited
The following individuals have participated in and contributed to
ESCC X.500/X.400 Task Force. Several of these individuals have
authored portions of this document. See Appendix H for
information regarding task force members and contributing authors
Allen Sturtevant (Chair) Lawrence Livermore National
Bob Aiken U.S. DOE/OER/SCS (now with NSF
Joe Carlson Lawrence Livermore National
Les Cottrell Stanford Linear Accelerator
Tim Doody Fermi National Accelerator
Tony Genovese Lawrence Livermore National
Arlene Getchell Lawrence Livermore National
Charles Granieri Stanford Linear Accelerator
Kipp Kippenhan Fermi National Accelerator
Connie Logg Stanford Linear Accelerator
Glenn Michel Los Alamos National
Peter Mierswa Digital Equipment
Jean-Noel Moyne Lawrence Berkeley
Kevin Oberman Lawrence Livermore National
Dave Oran Digital Equipment
Bob Segrest Digital Equipment
Tim Streater Stanford Linear Accelerator
Mike Sullenberger Stanford Linear Accelerator
Alan Turner Pacific Northwest
Linda Winkler Argonne National
Russ Wright Lawrence Berkeley
ESCC X.500/X.400 Task Force [Page 4]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992
1.
1.1. Abstract and
This document recommends an initial approach for the Phase
deployment of OSI Directory Services (X.500) and OSI Message
Services (X.400) within the ESnet community. It is anticipated
directly connected ESnet backbone sites will participate and
the suggestions set forth in this document
Section 7 of the "ESnet Program Plan" (DOE/OER-0486T, dated
1991) cites the need for further research and investigation in
areas of electronic mail and directory services. The
X.500/X.400 Task Force was created to address this need
Additionally, the task force is addressing the issues of
coordinated, interoperable deployment of OSI Directory Services
OSI Message Handling within the entire ESnet community. Since only
small subset of this community is actively pursuing these avenues
considerable effort must be made to establish the necessary "base"
build upon. If directly connected ESnet sites participate in
services, a consistent transition path will be ensured and
services provided will be mutually valuable and useful
X.500 and X.400 are continuously evolving standards, and
typically updated every four years. U.S. GOSIP (Government
Profile) Requirements are updated to define additional
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
are extended, consideration must be given as to the effect this
have on these existing services in the ESnet community. At
cross-roads, or when a sizeable increase in service functionality
desired, another "phase of deployment" may be in order. In
sense, there isn't a specific "final phase" goal, but rather
new releases (updates) to the level of existing services
1.2. Structure of this
X.500 is presented first. The issues of DSA (Directory
Agent) deployment, DSA registration, naming schema, involvement
the PSI White Pages Pilot Project, recommended object classes
recommended attribute types, information security,
optimization, user friendly naming and update frequency
addressed
In the area of X.400, issues relating to MTA (Message Transfer Agent
deployment, ESnet X.400 well-known entry points, ESnet backbone
X.400 well-known entry points, MTA registration, naming hierarchy
PRMD peering, bidirectional X.400-SMTP relaying
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
Standards Institute), GSA (General Services Administration) and
U.S. Department of Commerce, Patent and Trademark Office (PTO)
discussed
2. X.500 - OSI Directory
2.1. Brief
X.500 is a CCITT/ISO standard which defines a global solution for
distribution and retrieval of information (directory service).
X.500 standard includes the following characteristics:
management, powerful searching capabilities, a single
namespace, and a structured framework for the storage of information
The 1988 version of the X.500 standard specifies four models
define the Directory Service: the Information Model, the
Model, the Organizational Model and the Security Model. As is
nature of International standards, work continues on the 1992 X.500
standard agreements
The Information Model specifies how information is defined in
directory. The Directory holds information objects, which
information about "interesting" objects in the real-world.
objects are modeled as entries in an information base, the
Information Base (DIB). Each entry contains information about
object: ie, a person, a network, or an organization. An entry
constructed from a set of attributes each of which holds a
piece of information about the object. For example, to build
entry for a person the attributes might include "surname",
"telephoneNumber", "postalAddress", "rfc822Mailbox" (SMTP
address), "mhsORAddresses" (X.400 mail address)
"facsimileTelephoneNumber". Each attribute has an attribute
which describes the data that the attribute contains, for example,
alphanumeric string or photo data. The OSI Directory is
in that it defines several common types of objects and attributes
allows the definition of new ones as new applications are
that make use of the Directory. Directory entries are arranged in
hierarchical structure, the Directory Information Tree (DIT). It
this structure which is used to uniquely name entries. The name
an entry is its Distinguished Name (DN). It is formed by taking
DN of the parent's entry, and adding the the Relative
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
built by tracing the path from the root of the DIT to the entry
The Functional Model defines how the information is stored in
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
components of this model: the Directory User Agent (DUA),
application-process which interacts with the Directory on behalf
the user, and the Directory System Agent (DSA), which holds
particular subset of the Directory Information Tree and provides
access point to the Directory for a DUA
The Organizational Model of the OSI Directory describes the
in terms of the policy defined between entities and the
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
(using cryptographic keys). Authentication techniques are
when a user or process attempts a Directory operation through a DUA
2.2. Participation in the PSI White Pages Pilot
The PSI White Pages Pilot Project is currently the most well
established X.500 pilot project within the United States. For
country=US portion of the DIT, PSI currently has over 80
names registered. Of these, several are ESnet-related
The PSI White Pages Pilot Project is also connected to the
International Directory Service, PARADISE. This pilot
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
Yugoslavia. The combined totals for all of these
(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
recommended that directly connected ESnet backbone sites join
pilot project
2.3. Recommended X.500
Interoperability testing has not been performed on most X.500
implementations. Further, some X.500 functions are not
standards and are often added by implementors as
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,
University College London's publicly available X.500
(QUIPU) is recommended. This product is known to run on
UNIX-derivative platforms, operates over CLNS and RFC-1006 (
RFC-1006 being the currently recommended stack), and is currently
wide-spread use around the United States and Europe,
several ESnet backbone sites
Appendix C contains information on how to obtain QUIPU
A later phase deployment of X.500 services within the ESnet
will recommend products (either commercial or public domain)
pass conformance and interoperability tests
2.4. Naming
As participants in the PSI White Pages Pilot Project, ESnet
sites will align with the naming structure used by the Pilot.
structure is based upon a naming scheme for the US portion of the
developed by the North American Directory Forum (NADF) and
in RFC-1255. Using this scheme, an organization with
standing would be listed directly under the US node in the
DIT. Organizations chartered by the U.S. Congress as well
organizations who have alphanumeric nameforms registered with
are said to have national standing. Therefore, a backbone site
is a national laboratory would be listed under country=US
@c=US@o=Lawrence Livermore National
As would a site with an ANSI-registered organization name
@c=US@o=National Energy Research Supercomputer
A university would be listed below the state in which it is located
@c=US@st=Florida@o=Florida State
And a commercial entity would be listed under the city or state
which it is doing business, or "Doing Business As", depending
where its DBA is registered
@c=US@st=California@o=General
(or
@c=US@st=California@l=San Diego@o=General
A list of the current ESnet backbone sites, and their locations,
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
administering objects which reside below their respective portions
the DIT. Essentially, they must provide their own "Name
Authority". Although this may appear as an arduous task, it
nothing more than the establishment of a procedure for naming,
ensures that duplicate entries do not occur at the same level
a sub-tree of the DIT. For example, the Name Registration
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
Similarly, all other names created under
"@c=US@st=Massachusetts@o=MIT" portion of the DIT would
administered by the same MIT Name Registration Authority.
ensures that every Organizational Unit
"@c=US@st=Massachusetts@o=MIT" is unique. By default, each
Site Coordinator is assumed to be the Name Registration Official
their respective site. If an ESnet Site Coordinator does not wish
act in this capacity, they may designate another individual, at
site, as the Name Registration Official
2.4.1. Implications of the Adoption of RFC-1255 by
The North American Directory Forum (NADF) is comprised of
vendors positioning themselves to offer commercial X.500
Services. The NADF has produced several documents since
formation. The ones of notable interest are those which define
structure and naming rules for the commercially operated DIT
country=US. Specifically, for an Organization to exist
under c=US, it must be an organization with national-standing.
pages 12-13 of RFC-1255, national-standing is defined in
following way
"An organization is said to have national-standing if it
chartered (created and named) by the U.S. Congress. An
of such an organization might be a national laboratory.
is no other entity which is empowered by government to
national-standing on organizations. However, ANSI maintains
alphanumeric nameform registration of organizations, and
will be used as the public directory service basis
conferring national-standing on private organizations."
Thus, it appears that National Laboratories (e.g. LBL, LLNL)
considered organizations with national-standing. However,
ESnet backbone sites which are not National Laboratories may wish
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
c=US, but only if this is what they desire. It is important to
that NADF is not a registration authority, but a group of
providers defining a set of rules for information sharing and
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
Several of the ESnet backbone sites are not National
(e.g. CIT, FSU, GA, ISU, MIT, NYU, UCLA and UTA). Typically,
these sites, a small collection of researchers are involved
performing DOE/OER funded research. Thus, this set of researchers
a given site may not adequately represent the total X.500
at their facility. Additionally, ESnet Site Coordinators at
facilities may not be authorized to act as the Name
Official for their site. So the question is, how do these
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
Site Coordinator may be able to establish and administer
DSA to master the DOE/OER portion of the site's local DIT
e.g. "@c=US@st=@o=@ou=Physics". Before
this action, it would be prudent for the Site Coordinator
notify or seek approval from some responsible entity. At
time that the site wishes to manage its own
within the X.500 DIT, the ESnet Site Coordinator would have
make arrangements to put option 2 into effect
2. If the site is currently operating an X.500 DSA, the
Site Coordinator may be able to work out an agreement with
current DSA administrator to administer a portion of
site's local DIT which would represent the DOE/OER
at that site. For example, if the site were
administering the organization "@c=US@st
Massachusetts@o=Massachusetts Institute of Technology",
ESnet Site Coordinator might then be able to administer
organizational unit "@c=US@st=Massachusetts@o=
Institute of Technology@ ou=Physics".
2.4.3. Naming Structure Below the o=
The structure of the subtree below the organization's node in the
is a matter for the local organization to decide. A site's
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
organization before deciding how to structure the local DIT
Some organizations currently participating in the Pilot
established a simple structure, choosing to limit the number
organizational units and levels of hierarchy. Often this is done
order to optimize search performance. This approach has the
benefit of insulating the local DIT from administrative
within the organization. Others have chosen to closely model
organization's departmental structure. Often this approach
more natural and can enhance the information obtained from
the Directory
Below are experiences from current DSA managers, describing the
they structured their local DIT and the reasons for doing so. A
may find this information helpful in determining how to
their local DIT. Ultimately this decision will depend upon the
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
straightforward process. Basically, the University
organized on a College/Department basis. We decided to
that "real" structure in the DIT for two major reasons
"(a) It duplicates the way we do business, so interfacing
X.500 directory with the "real world" is easier
"(b) With 600+ departmental units and 11,000+ people (to
30,000+ once we add students), a "zero" (everybody at top)
"one" deep (600 departments at top) arrangement just didn'
hack it - it was deemed necessary that you be able to do
some 120 or 140 county office entries under the
service, it's a BIT unwieldy there). However, with some 20
college-level entries at the top, and the "average"
having 30 departments, and the "average" department being
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
from Tel-Com and just put everyone directly under "O=
University".
"Actually, there is an exception, when the DSA was first set
and we had not received a database yet, I configured the DIT
include "OU=Computer Science", under which myself and one
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
for everyone else I decided not to attempt to separate
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)
splitting based on internal department name and ended up
flat. Our primary reason was load and search times, which
2-3 times faster for flat organization."
Paul Mauvais of Portland State University
"We originally set up our DIT by simply loading our
phone book into one level down from the top (e.g. OU=
and Staff, OU=Students, OU=Computing Services).
"I'd love to have an easy way to convert our flat faculty
staff area into departments and colleges, but the time
convert the data into the separate OU's is probably more than
have right now."
Mohamed Ellozy of Dana-Farber Cancer Institute
"Here we have a phone database that includes department, so
got the ou's with no effort. We thus never went the flat
way."
Dan Moline of TRW
"Well - we're still in the process of defining our DIT.
comes under the international companies DBA. Our part
the PSI White Pages Pilot defines the DIT for our space
defense organization here in Redondo Beach (however,
organized the structure to adhere to TRW corporate). We
from our manpower DB for our S&D personnel. We're trying
get corporate's DB for possible input
"However, arranging your DIT by organizations (at least
corps) presents a problem; things are always being reorganized
We were DSO now we're SSO!!! We still have some of our
domain name for DNS tied to organizations that have not
for years
"So we are currently redesigning our DIT to try to fit NADF 175
(something more geographically). Our reasoning was
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
in the PSI White Pages Pilot. @c=US@O=SRI
supports the information for one OU only (i.e., a local
and decision). In order to not give the false impression
all SRI information was contained under this O=
International, I used OU=Network Information Systems Center
If I were to structure the DIT for all of SRI, I'm sure that
thinking would yield a much different structure."
Russ Wright of Lawrence Berkeley Laboratory
"Since we don't have much organizational information in
staff database, I have to stick to a fairly flat structure.
have two OUs. One is for permanent staff, the other is
guests (there is a flag in our database that is set
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
publications). Staff and Guests would reside under
Personnel OU."
Peter Yee of NASA Ames
"I broke up my DIT at the NASA Center level. NASA is made
nearly 20 Centers and Facilities. The decision to break up
this level was driven by several factors
"1. Control of the local portion of the DIT should reside
the Center in question, particularly since the Center
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
UNIX servers. Smaller would be a waste, larger would
too much memory
"3. Representatives from several Centers have contacted
asking if they could run their own DSAs so that they
experiment with X.500. Thus the relevant DSA needs to be
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
in later Phases, or added dynamically as the need arises
To make X.500 truly useful to the ESnet community as a White
service, it is recommended that the following minimum
should be stored in the X.500 database
Information ASN.1 Attribute Type
----------- -------------------- -------
Locator Info commonName Allen
surname
postalAddress
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.
mhsORAddresses /PN=Allen Sturtevant/O=NERSC
/PRMD=ESnet/ADMD= /C=US
otherMailbox DECnet: ESNIC::
The above list of attributes comprises a minimum set which
recommended for a person's entry. However, you may chose to
some attributes for reasons of privacy or legality. Note that
X.500 standard requires that the surname and commonName attributes
present. If an individual's phone number and/or address cannot
provided, they should be replaced by the site's "Information
Number" and postal address to allow some means of contacting
person
2.5.1. Information
It is understood that placing this type of information in X.500
equivalent to putting the "Company Phone Book" on-line in
Internet. Different sites may treat this information differently
Some may view it as confidential, while others may view this data
open to the public. In any case, it was recommended that ESnet
discuss the implications with their respective legal
before actually making their information openly available.
currently exists minimal access control in several X.500
implementations
2.6. Accessing the X.500 Directory
The PSI White Pages Pilot Project software provides
interfaces to the information in the X.500 Directory. Non
interactive access mechanisms (e.g. WHOIS, FINGER and
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
many workstations and hosts. Such hosts could immediately
advantage of the X.500 service with no additional software
reconfiguration needed. However, since these methods are non
interactive, they only provide a way to search for and
information in the Directory but no way to modify information
2.6.1. Directory Service via
The Pilot Project software allows you to configure the X.500
Directory service to be made available via a network port offering
emulation of the SRI-NIC WHOIS service. UNIX-based hosts and
hosts running Multinet typically come configured with the
service. Users at their workstations would then be able to issue
simple WHOIS command to a known host running a DSA to
information about colleagues at their site or at other ESnet sites
For example, the command
whois -h wp.lbl.gov
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
form for consistency within the ESnet community
2.6.2. Directory Service via Electronic
The Pilot Project software also allows the X.500 Directory service
be made available via electronic mail. A user who sends
electronic mail message to a known host running a DSA containing
WHOIS-like command on the subject line, would then receive a
mail message containing the results of their query
2.6.3. Directory Service via
The X.500 Directory service could also be made available via
FINGER service. Although this access method does not come with
PSI Pilot Project software, several sites have already implemented
FINGER interface to the X.500 Directory. For ease of use
consistency, a single FINGER interface should be selected,
individual implementations within the ESnet community should
to this interface
2.6.4. Directory Service via Specialized
Many X.500 Directory User Agents (DUAs) are widely available.
of these come with the PSI Pilot Project software. Other DUAs,
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
to the X.500 Directory allowing browsing, searching, listing
modifying data in the Directory. However, in most cases, use
these DUAs requires the Pilot Project software be installed on
host system. Only a few of these DUAs and their capabilities
described below
o DISH - A User Agent which provides a textual interface to
X.500 Directory. It gives full access to all elements of
Directory Access Protocol (DAP) and as such may be complex
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
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
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
Smaller workstations and personal computers lack the computing
or necessary software to implement a full OSI protocol stack. As
consequence, several "light-weight" protocols have been
whereby the DAP runs on a capable workstation and exports a
interface to other end-systems. One such "light weight" protocol
the Directory Assistance Service (DAS), is incorporated in the
Pilot Project software. Another "light weight" protocol, DIXIE,
developed at the University of Michigan. Publicly available
Agents for both the MAC and PC have been developed using the DA
service and the DIXIE protocol. So long as you have the
Project software running on one host, you can provide these
Agents on many end-systems without having to install the
software on all those end-systems
For further information about available Directory User Agents,
RFC-1292, "Catalog of Available X.500 Implementations".
2.7. Services Provided by
Currently, there are several ESnet backbone sites which are
their own DSAs within the PSI White Pages Pilot Project. It
anticipated that directly connected ESnet backbone sites
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
presently do not have the time, expertise or equipment to
X.500 services. The mechanism for doing this is described in
2.7.5 below. Additionally, ESnet will provide a variety of
in support of the entire X.500 community. These are also
in the following sections
2.7.1. X.500 Operations Mailing
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.
sites joining the ESnet X.500 community will be announced on
mailing list. New DSA administrators will be able to solicit
from more experienced administrators. When a site brings up a
X.500 DSA, the DSA manager should notify the ESnet DSA manager so
to ensure they are promptly added to the mailing list
General discussion: x500-ops@es.
To subscribe: x500-ops-request@es.
2.7.2. Accessing the X.500
ESnet has made the X.500 service openly available to the entire
community via each of the access methods described in Section 2.6
above. Host WP.ES.NET provides TELNET access, FINGER and
emulations, querying via electronic mail, as well as remote
via light-weight protocols. By making these services
available, we hope to acquaint more users with the features
capabilities of X.500.
To try out some of the X.500 User Agents, simply TELNET to WP.ES.
and login as user "fred"; no password is required. You have
choice of running the Fred or Pod User Agents. Fred provides
command line interface while Pod provides an X-windows
interface. You can browse through the global X.500 DIT, search
persons in various organizations, and even modify your own entry
you have one
Host WP.ES.NET also provides access to the X.500 Directory
emulations of the FINGER and WHOIS utilities. These
support a user-friendly-naming (UFN) scheme that simplifies
syntax necessary to search for persons in other organizations.
following WHOIS command lines illustrate searching for persons
various ESnet sites, utilizing the UFN syntax (similar FINGER
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,
whois -h wp.es.net servey,
whois -h wp.es.net logg,
whois -h wp.es.net "russ wright",
For further information about User Friendly Naming, see
Hardcastle-Kille's working document titled, "Using the OSI
to Achieve User Friendly Naming".
2.7.3. Backbone Site
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
of the DIT, while universities and commercial entities will
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
under the node "@c=US@o=Energy Sciences Network". These entries
actually be aliases which point to the site's "real"
entry. Therefore, ESnet backbone sites will be listed in
different places in the DIT and one could search for them in
location
2.7.4. Multiprotocol Stack
OSI applications currently run over many different transport/
protocols, a factor which hinders communication between OSI
nodes. In order to facilitate communication, the ISODE may
configured at compile time to support any combination of
following stacks
RFC-1006 over TCP/
TP0 over X.25
TP0 over X.25 (84)
TP0 over the TP0-
TP4 over
Within the ESnet community, the stacks of interest are RFC-1006
TCP/IP, TP4 over CLNP, and TP0 over X.25. If a backbone site's
is not running over all three of these stacks, it may
receive referrals to a DSA that it can not connect to directly,
the operation can not proceed. Since the ESnet DSAs will
configured to operate over all of the "stacks of interest," they
serve as relay DSAs between site DSAs that do not have
connectivity. The site's DSA manager will need to contact the
DSA manager to arrange for this relaying to occur. Backbone
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
of interest as possible
2.7.5. Managing a Site's X.500
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
site to join the PSI Pilot Project and the ESnet X.500 community.
order to accomplish this, the site must provide the ESnet DSA
with information about the people to be included in the X.500
Directory. This information can usually be obtained from your Site'
Personnel Database
ESnet will only maintain a limited amount of information on behalf
each person to be represented in the Directory. The attribute
listed in the table in Section 2.5 show the maximum amount
information which the ESnet DSA will support for a person's entry
the Directory. This set of attribute types is a small subset of
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
is as follows: the data should be contained in a flat, ASCII
file, one record (line) per person, with a specified
separating the fields of the record. More detailed information and
sample of a site-supplied data file can be found in Appendix D
2.7.5.1. Open Availability of Site
Although the PSI Pilot Project allows you to control who may
Directory objects and their attributes, any information you
about persons at your site to be stored in the ESnet DSA will
considered world readable. This policy is necessary in order
minimize the administrative cost of managing potentially
organizational objects within the ESnet DSA. If your site
that it does not wish to have certain information about its
publicly known (e.g. work telephone number) then you should
provide this information to the ESnet DSA manager or you
consider installing and administering your own DSA
2.7.5.2. Access Methods for Local
Backbone sites which choose the option of having the ESnet DSA
their organization's X.500 information should make the
of the X.500 service known to their local users. All of the
described in Section 2.7.2 are available for use, but none of
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
will need to make one host available to run the emulation of
FINGER service. Although the resulting query will ultimately
directed to the remote ESnet DSA, the search will appear to be
to the users at that site. For example, a user on a workstation
site XYZ could type the following, omitting their local domain
as this is implied
finger jones@
This will retrieve information about user Jones at site XYZ (wp
the name or alias of a host at site XYZ, i.e. wp.XYZ.GOV). The
coordinator will need to contact the ESnet DSA manager to arrange
set up for this service
2.7.5.3. Limitations of Using ESnet
Since the ESnet DSA will potentially be mastering information
behalf of numerous backbone sites, limits will need to be placed
the volume of site information stored in the ESnet DSAs. These
enforced to ensure DSA responsiveness, as well as to
administrative maintenance. The limits are
Item Maximum
---- -------------
X.500 Organizations 1
Organizational Units 50
Organizational Unit Depth 3
Object Entries 5,000
Update Frequency 1
Aliases n/
Object/Attribute Access Control n/
One week before each monthly update cycle, a message will be sent
the x500-ops@es.net mailer to remind the sites that an update
is approaching. If no changes are required to the site information
the reminder message can be ignored and the existing version of
information will be used. If the information is to be updated,
complete replacement of all information must be supplied to the
DSA manager before the next update cycle. More detailed
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=
For ESnet to provide high quality X.500 services to the
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
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
backbone sites operating their own X.500 DSAs configure them with
of the ESnet DSAs as their parent DSA. This provides
advantages to the ESnet community
1. The ESnet DSAs will be monitored by the NERSC's 24-
Operations Staff. Additionally, ESnet plans to deploy
(2) DSAs in geographically disperse locations to
reliability and availability
2. All queries to Level-0 DSAs remain within the ESnet high-
backbone
3. If network connectivity is lost to all external Level-0 DSAs
X.500 Level-0 connectivity will still exist within the
backbone
2.9. X.500 Registration
X.500 organization names must be nationally unique if they
directly below the c=US level in the DIT structure.
unique names must be registered through an appropriate
authority, i.e., one which grants nationally unique names
X.500 organizational unit names need to be unique relative to
node directly superior to them in the DIT. Registration of
names should be conducted through the "owner" of the superior node
The registration of X.500 names below the organization level
usually a local matter. However, all siblings under a given node
the DIT must have unique RDNs
See Section 4 for a more complete description of OSI
issues and procedures
2.10. Future X.500 Issues to be
2.10.1. ADDMDS Interoperating with
This is a problem which currently does not have an answer. The
of Administrative Directory Management Domains (ADDMDs)
with Private Directory Management Domains (PRDMDs) is just
to be investigated by several groups interested in solving
problem
2.10.2. X.400 Interaction with X.500
The current level of understanding is that X.400 can benefit from
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
both of these features in a fully integrated fashion across
vendors. As the standards and technology evolve, consideration
have to be given in applying these new functions to the
ESnet X.500/X.400 services environment
2.10.3. Use of X.500 for NIC
Work is currently being performed in the IETF to place
information on-line in an Internet-based X.500 service
2.10.4. Use of X.500 for Non-White Pages
The PSI White Pages Pilot Project has caused increasing and
use of X.500 as a white pages services within the Internet community
However, the X.500 standard provides for much more than just
service. Application processes, devices and security objects
just a few of the objects to be considered for future
in the global X.500 database
2.10.5. Introduction of New X.500
Thought will have to be given to the use of commercial X.500
in the future as QUIPU (the implementation recommended in this paper
may not meet all of the needs of the ESnet community. As
products mature and become stable, they will have to be
into the ESnet X.500 service in a way which ensures
and reliability
2.10.6. Interaction of X.500 and
There is every indication that DECdns and X.500 will interoperate
some fashion in the future. Since there is an evolving
namespace (i.e. OMNI) and an evolving X.500 DIT (i.e. NADF),
consideration should be given to how these two name trees
interact. All of this will be driven by the Digital
Corporation's decisions on how to expand and incorporate its
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
3.1. Brief
In 1984 CCITT defined a set of protocols for the exchange
electronic messages called Message Handling Systems (MHS) and
described in their X.400 series of recommendations. ISO
these recommendations in their standards (ISO 10021). The name
by ISO for their system was MOTIS (Message-Oriented Text
Systems). In 1988 CCITT worked to align their X.400
with ISO 10021. Currently when people discuss messaging systems
use the term X.400. These two systems are designed for the
purpose of exchanging electronic messages in a store and
environment. The principle use being made of this system today is
support electronic mail. This section will give an overview of X.400
as used for electronic mail. In the following sections, the
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
System (MTS) accessed via a User Agent (UA). A UA is an
that interacts with the Message Transfer System to submit messages
behalf of a user. A user is referred to as either an
(when sending a message) or a Recipient (when receiving one).
process starts out when an Originator prepares a message with
assistance of their UA. The UA then submits the message to the
for delivery. The MTS then delivers the message to one or
Recipient UAs
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
______ | _______ _______ | ______
| | | MTS | | | | | | |
| UA |<----|---->| MTA |<------>| MTA |<---|--->| UA |
|______| | |_______| |_______| | |______|
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|
The MTS provides the general store-and-forward message
service. It is made up of a number of distributed Message
Agents (MTA). Operating together, the MTAs relay the messages
deliver them to the intended recipient UAs, which then makes
messages available to the recipient (user).
The basic structure of an X.400 message is an envelope and
(i.e. message). The envelope carries information to be used
transferring the message through the MTS. The content is the
of information that the originating UA wishes delivered to
recipient UA. There are a number of content types that can
carried in X.400 envelopes. The standard user message content
defined by X.400 is called the Interpersonal (IP) message. An
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
contains the message control information. The body contains the
message. The body may consist of a number of different body parts
For example one IP message could carry voice, text, Telex
facsimile body parts
The Management domain (MD) concept within the X.400
defines the ownership, operational and control boundary of an X.400
administration. The collection consisting of at least one MTA
zero or more UAs owned by an organization or public
constitutes a management domain (MD). If the MD is managed by
public provider it is called an Administration Management
(ADMD). The MD managed by a company or organization is called
Private Management Domain (PRMD). A Private MD is considered
exist entirely within one country. Within that country a PRMD
have access to one or more ADMDs
Each MD must ensure that every user (i.e UA) in the MD has at
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
o Administration Management
o Private Management
o Organization
o Organizational Unit
o
o Given
o
o Generational
An O/R name must locate one unambiguous O/R UA if the message is
be routed correctly through the Message Transfer Service.
each MD along the route a message takes determines the next MD's
to which the message should be transferred. No attempt is made
establish the full route for a message, either in the originating
or in any other MD that acquires the store and forward
for the message
Messages are relayed by each MD on the basis of the Management
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.
which point, the other attributes in the name are used to
route to the recipient UA. Internal routing within a MD is
responsibility of each MD
3.2. ESnet X.400 Logical
Currently within the ESnet community message handling services
implemented with a number of different mail products, resulting
what is classically known as an "n-squared" problem. For example
let's say that LLNL only uses QuickMail on site, PPPL only
MAIL-11 (VMS MAIL), and CEBAF only uses SMTP mail. For LLNL to
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
support MAIL-11 and QuickMail locally. Identically, this
exists for CEBAF
To alleviate this problem, a logical X.400 backbone must
established through out the entire ESnet backbone. Then, each
backbone site will be responsible for only providing
between it's local mail domains (QuickMail, MAIL-11, SMTP Mail,
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"
directly connected ESnet backbone sites
3.3. Naming
The name-spaces for X.500 and X.400 are completely different and
structured to meet different needs. The X.500 name-space
typically organized to allow quick, optimized searching; while
X.400 ORname is used to forward an X.400 message through
"levels" of MTAs (X.400 Message Transfer Agents).
ESnet backbone sites will participate in the X.400
through one of two options; either participating in the ESnet
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
ESnet backbone sites participating in the ESnet PRMD will have
X.400 name syntax as follows
/.../O=/PRMD=ESnet/ADMD= /C=US
A few examples of a possible X.400 ORnames using the above
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
name hierarchy
3.3.2. Operating a Site Private Management
ESnet backbone sites which operate a PRMD will have an X.400
syntax as follows
/.../O=/PRMD=/ADMD= /C=US
A few examples of a possible X.400 ORnames using the above
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= level in the
hierarchy. This MTA will peer with the ESnet PRMD MTA
3.3.3. Detailed Name
GOSIP places several limits on allowable ORnames. After
/O=<organization> name, up to four levels
/OU= names are allowed. The ORname string
then completed with the /PN=<personal_name> field
All ORname fields must use characters from the ISO
character set. Additionally, the following name length
apply
PRMD Names 16
Organization Names 64
Organizational Unit Names 32
Personal Names 64
NOTE: A 40 character limit for Personal Names is now
studied by the CCITT
Within these name constraints, the architecting of an organization'
name space is a local matter. Sites are encouraged to consider
of use and stability when determining their naming structure
3.4. X.400
In the IP environment a SMTP MTA could use the Domain Name
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
recipient. With X.400, MTAs must know the remote MTAs name
password along with connection information. This is because
access control requirements on some X.400 systems. In X.400 MHS
information will, at some future date, be provided by X.500. In
mean time the routing and connection process within the X.400
community is table driven. This solution requires a coordination
distribution effort to ensure a quick and reliable update of
tables
The current thinking on the problem of X.400 routing is to
the X.400 address space into a hierarchy, with each node in
hierarchy representing the entry point for an X.400 domain.
nodes have been commonly called Well Known Entry Points (WEPs).
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/ADM