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.

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. Il
following WHOIS command lines illustrate searching for persons at
various ESnet sites, utilizing the UFN syntax (similar FINGER command
lines could also be constructed):

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 (eg 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, ie 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:

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, ie, 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 (ie OMNI) and an evolving X.500 DIT (ie 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.

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). Il
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.

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 (ie 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]

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:

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. Per esempio:

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.

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 (eg 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. Per esempio:

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 (eg 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.

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:

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. Il
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
(eg, people, information processing systems and applications) must
be unambiguously identifiable on a global basis. These objects may
be defined by a variety of organizations, eg, 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 US
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 US 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 US 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 US 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:

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:

ANSI registration requests can be forwarded automatically to the GSA.
This is the equivalent of registering with both ANSI and GSA. Il
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 US 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 US 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 US 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:

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 (eg AT&T, MCI, US 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.

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]

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

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.

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

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 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
(ie 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 (ie 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 (ie 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. Un
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).

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'. Il
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.

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.

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

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:

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:

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

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 US 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. Il
objective is to see X.500 widely deployed and used in the US
Government. X.500 is expected to be in the next release of the US
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 US 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.

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.

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.

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.

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. Il
organizational work is being done jointly by IETF working groups and
RARE Working Group 1.

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

This software supports the development of certain kinds of OSI
protocols and applications. Here are the details:

o The ISODE is not proprietary, but it is not in the public
domain. This was necessary to include a "hold harmless"
clause in the release. The upshot of all this is that anyone
can get a copy of the release and do anything they want with
it, but no one takes any responsibility whatsoever for any
(mis)use.

o The ISODE runs on native Berkeley (4.2, 4.3) and AT&T System V
systems, in addition to various other UNIX-like operating
systems. No kernel modifications are required.

o Current modules include:

- OSI transport service (TP0 on top of TCP, X.25 and CONS;
TP4 for SunLink OSI)

- OSI session, presentation, and association control services

- ASN.1 abstract syntax/transfer notation tools, including:

1. Remote operations stub-generator (front-end for remote
operations)

2. Structure-generator (ASN.1 to C)

3. Element-parser (basic encoding rules)

- OSI reliable transfer and remote operations services

- OSI directory services

- OSI file transfer, access and management

- FTAM/FTP gateway

- OSI virtual terminal (basic class, TELNET profile)

o ISODE 7.0 consists of final "IS" level implementations with the
exception of VT which is a DIS implementation. The ISODE also

ESCC X.500/X.400 Task Force [Page 58]

RFC 1330 X.500 and X.400 Plans for ESnet May 1992
contains implementations of the 1984 X.400 versions of ROS and
RTS.

o Although the ISODE is not "supported" per se, it does have a
problem reporting address, Bug-ISODE@XTEL.CO.UK. Bug reports
(and fixes) are welcome by the way.

o The discussion group ISODE@NISC.SRI.COM is used as an open
forum on ISODE. Contact ISODE-Request@NISC.SRI.COM to be added
to this list.

o The primary documentation for this release consists of a five
volume User's Manual (approx. 1000 pages) and a set of UNIX
manual pages. The sources to the User's Manual are in LaTeX
format. In addition, there are a number of notes, papers, and
presentations included in the documentation set, again in
either LaTeX or SLiTeX format. If you do not have LaTeX, you
should probably get a hardcopy from one of the distribution
sites below.

ISODE/QUIPU Distribution Sites

The FTP or FTAM distributions of ISODE-7.0 consists of 3 files. Il
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 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.

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.

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 (ie 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.

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.

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

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 (eg, in a mail message), there is
a need to have a user-oriented string representation of
distinguished name.

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.

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.

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.

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.

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.

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]

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.

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

The X.400 addresses do start to appear on business cards. Il
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.

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