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
use of X.500 in two ways:
1. Lookup of message recipient information.
2. Lookup of message routing information.
X.400 technology and products, as they stand today, do not support
both of these features in a fully integrated fashion across multiple
vendors. As the standards and technology evolve, consideration will
have to be given in applying these new functions to the production
ESnet X.500/X.400 services environment.
2.10.3. Use of X.500 for NIC Information
Work is currently being performed in the IETF to place NIC
information on-line in an Internet-based X.500 service.
2.10.4. Use of X.500 for Non-White Pages Information
The PSI White Pages Pilot Project has caused increasing and popular
use of X.500 as a white pages services within the Internet community.
However, the X.500 standard provides for much more than just this
service. Application processes, devices and security objects are
just a few of the objects to be considered for future incorporation
in the global X.500 database.
2.10.5. Introduction of New X.500 Implementations
Thought will have to be given to the use of commercial X.500 products
in the future as QUIPU (the implementation recommended in this paper)
may not meet all of the needs of the ESnet community. As commercial
products mature and become stable, they will have to be incorporated
into the ESnet X.500 service in a way which ensures interoperability
and reliability.
2.10.6. Interaction of X.500 and DECdns
There is every indication that DECdns and X.500 will interoperate in
some fashion in the future. Since there is an evolving DECdns
namespace (i.e. OMNI) and an evolving X.500 DIT (i.e. NADF), some
consideration should be given to how these two name trees will
interact. All of this will be driven by the Digital Equipment
Corporation's decisions on how to expand and incorporate its DECdns
product with X.500.
3. X.400 - OSI Message Handling Services
3.1. Brief Tutorial
In 1984 CCITT defined a set of protocols for the exchange of
electronic messages called Message Handling Systems (MHS) and is
described in their X.400 series of recommendations. ISO incorporated
these recommendations in their standards (ISO 10021). The name used
by ISO for their system was MOTIS (Message-Oriented Text Interchange
Systems). In 1988 CCITT worked to align their X.400 recommendations
with ISO 10021. Currently when people discuss messaging systems they
use the term X.400. These two systems are designed for the general
purpose of exchanging electronic messages in a store and forward
environment. The principle use being made of this system today is to
support electronic mail. This section will give an overview of X.400
as used for electronic mail. In the following sections, the term
X.400 will be used to describe both the X.400 and MOTIS systems.
The basic model used by X.400 MHS is that of a Message Transfer
System (MTS) accessed via a User Agent (UA). A UA is an application
that interacts with the Message Transfer System to submit messages on
behalf of a user. A user is referred to as either an Originator
(when sending a message) or a Recipient (when receiving one). The
process starts out when an Originator prepares a message with the
assistance of their UA. The UA then submits the message to the MTS
for delivery. The MTS then delivers the message to one or more
Recipient UAs.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
______ | _______ _______ | ______
| | | MTS | | | | | | |
| UA |<----|---->| MTA |<------>| MTA |<---|--->| UA |
|______| | |_______| |_______| | |______|
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|
The MTS provides the general store-and-forward message transfer
service. It is made up of a number of distributed Message Transfer
Agents (MTA). Operating together, the MTAs relay the messages and
deliver them to the intended recipient UAs, which then makes the
messages available to the recipient (user).
The basic structure of an X.400 message is an envelope and content
(i.e. message). The envelope carries information to be used when
transferring the message through the MTS. The content is the piece
of information that the originating UA wishes delivered to the
recipient UA. There are a number of content types that can be
carried in X.400 envelopes. The standard user message content type
defined by X.400 is called the Interpersonal (IP) message. An IP
message consists of two parts, the heading and body. The heading
contains the message control information. The body contains the user
message. The body may consist of a number of different body parts.
For example one IP message could carry voice, text, Telex and
facsimile body parts.
The Management domain (MD) concept within the X.400 recommendations
defines the ownership, operational and control boundary of an X.400
administration. The collection consisting of at least one MTA and
zero or more UAs owned by an organization or public provider
constitutes a management domain (MD). If the MD is managed by a
public provider it is called an Administration Management Domain
(ADMD). The MD managed by a company or organization is called a
Private Management Domain (PRMD). A Private MD is considered to
exist entirely within one country. Within that country a PRMD may
have access to one or more ADMDs.
Each MD must ensure that every user (i.e UA) in the MD has at least
one name. This name is called the Originator/Recipient (O/R) Name.
O/R Names are constructed from a set of standard attributes:
o Country Name
o Administration Management Domain
o Private Management Domain
o Organization Name
o Organizational Unit Name
o Surname
o Given name
o Initials
o Generational Qualifier
An O/R name must locate one unambiguous O/R UA if the message is to
be routed correctly through the Message Transfer Service. Currently
each MD along the route a message takes determines the next MD's MTA
to which the message should be transferred. No attempt is made to
establish the full route for a message, either in the originating MD
or in any other MD that acquires the store and forward responsibility
for the message.
Messages are relayed by each MD on the basis of the Management domain
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:
/PN=Smith/OU=Computations/O=LLNL/PRMD=ESnet/ADMD= /C=US/
/PN=Jones/OU=Physics/O=PPPL/PRMD=ESnet/ADMD= /C=US/
These sites will operate an MTA at the /O=<organization> level in the
name hierarchy.
3.3.2. Operating a Site Private Management Domain
ESnet backbone sites which operate a PRMD will have an X.400 name
syntax as follows:
/.../O=<org>/PRMD=<site>/ADMD= /C=US/
A few examples of a possible X.400 ORnames using the above syntax
are:
/PN=Smith/O=Computations/PRMD=LLNL/ADMD= /C=US/
/PN=Jones/O=Physics/PRMD=PPPL/ADMD= /C=US/
These sites will operate an MTA at the /PRMD=<PRMD> level in the name
hierarchy. This MTA will peer with the ESnet PRMD MTA.
3.3.3. Detailed Name Structure
GOSIP places several limits on allowable ORnames. After the
/O=<organization> name, up to four levels of
/OU=<organizational_unit> names are allowed. The ORname string is
then completed with the /PN=<personal_name> field.
All ORname fields must use characters from the ISO printable
character set. Additionally, the following name length restrictions
apply:
PRMD Names 16 characters
Organization Names 64 characters
Organizational Unit Names 32 characters
Personal Names 64 characters
NOTE: A 40 character limit for Personal Names is now being
studied by the CCITT.
Within these name constraints, the architecting of an organization's
name space is a local matter. Sites are encouraged to consider ease
of use and stability when determining their naming structure.
3.4. X.400 Routing
In the IP environment a SMTP MTA could use the Domain Name Service
(DNS) to locate connection information for the host closest to the
recipient. With X.400, MTAs must know the remote MTAs name and
password along with connection information. This is because of
access control requirements on some X.400 systems. In X.400 MHS this
information will, at some future date, be provided by X.500. In the
mean time the routing and connection process within the X.400
community is table driven. This solution requires a coordination and
distribution effort to ensure a quick and reliable update of these
tables.
The current thinking on the problem of X.400 routing is to decompose
the X.400 address space into a hierarchy, with each node in this
hierarchy representing the entry point for an X.400 domain. These
nodes have been commonly called Well Known Entry Points (WEPs). Each
of these WEPs represent one X.400 MHS domain. For example:
/O=LBL/PRMD=ESnet/ADMD= /C=US/
/O=NERSC/PRMD=ESnet/ADMD= /C=US/
/PRMD=ESnet/ADMD= /C=US/
/PRMD=ANL/ADMD= /C=US/
/PRMD=PNL/ADMD= /C=US/
To minimize the number of hops between Originators and Recipients it
is the current recommendation of the X.400 community that every PRMD
peer with all other PRMDs.
The ESnet backbone will provide connectivity between multiple PRMDs
(the ESnet PRMD and any site operated PRMDs), each with associated
well-know entry point MTAs. Each of these PRMD-level MTAs must be
configured with routing and mapping information about each other to
enable peer-to-peer PRMD routing. These routing tables should be
updated immediately upon the discovery of new/changed X.400
connectivity information. These tables will be made available to the
ESnet community via the ESnet Information Server. Once placed on-
line, a notification message announcing the availability of this new
routing information will be sent to every WEP owner via the E-mail
mechanism described in Section 3.5.1. It is recommended that WEP
administrators should retrieve this new routing information and
update their MTAs within 10 working days.
The well-known entry point MTA for each PRMD can route down to an
Organizational level MTA or laterally to the well-known entry point
of a peer PRMD MTA.
For example, the ESnet MTA would route a message with the address:
/PN=Funk/OU=CS/O=PPPL/PRMD=ESnet/ADMD= /C=US/
to a well-known entry point for PPPL (O=PPPL). PPPL must own and
operate their own X.400 MTA, and it must be configured to accept
X.400 messages from the ESnet MTA. Thus, the interpretation of
remaining "/PN=Funk/OU=CS" is left to the PPPL MTA to route.
Mail sent from PPPL's MTA would be routed to the ESnet's MTA (PRMD)
to be eventually routed to its destination.
The ESnet MTA will also route to peer MTAs which are well-known entry
points for other PRMDs (e.g. ESnet backbone site PRMDs, XNREN, Hughes
Air Craft, NASA, CDC). For example, the ESnet MTA would route a
message with the address:
/PN=Smith/OU=MS/O=RL/PRMD=PNL/ADMD= /C=US/
to a well-known entry point for PNL (PRMD=PNL). PNL must own and
operate their own X.400 MTA, and it must be configured to accept
X.400 messages from the ESnet MTA (as well as possibly other PRMDs).
Thus, the interpretation of the remaining "/PN=SMITH/OU=MS/O=RL" is
left to the PNL MTA to route.
Mail sent from PNL's MTA (PRMD) would be routed to the well-known
entry point for the PRMD indicated in the destination address.
Additionally, a site operated PRMD must be able to route mail to any
other peer-PRMD within the ESnet community.
3.4.1. Responsibilities in Operating an X.400 PRMD MTA
If the X.400 world were to operate exactly as the standard
recommends, PRMDs would only peer with other PRMDs when connectivity
is available and traffic demand is sufficient, and would utilize ADMD
services to reach all other PRMDs. In reality, many PRMDs will not
subscribe to an ADMD service and will only be reachable through PRMD
peering.
Most communities, such as the ESnet, desire the fullest PRMD
interconnectivity possible to minimize the need for ADMD services.
Community PRMD operational requirements stem from a policy of
achieving large scale peering among PRMD operators within the
community.
Work is continuing in the IETF X.400 Operations Working Group to
produce an RFCthat 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
document. It is the recommendation that all ESnet PRMDs follow the
requirements specified in this document.
As an overview, this document specifies that each PRMD will provide
at least one WEP and that all PRMDs must be interconnected. There
are a number of PRMDs in the International X.400 service that have
different communication stack requirements. For example:
Stack 1 Stack 2 Stack 3 Stack 4
------- ------- ------- -------
Transport Layer 4 TP0 TP4 RFC-1006 TP0
Network Service 1-3 X.25 CLNS TCP/IP CONS
To meet the requirement that all PRMDs must be interconnected a PRMD
must support one or more of the above stacks. For stacks that are
not supported the PRMD must negotiate with another PRMD or ADMD to
relay messages to a Management Domain that does support the other
stacks.
The PRMD requirements also suggest that PRMDs support downgrading of
X.400 1988 to X.400 1984. Also, the PRMD must be reachable from the
Internet Mail service. This means the PRMD must maintain an Internet
Mail/X.400 gateway.
In all cases, members of the ESnet community who operate a PRMD
should notify ESnet of the WEP and MTA information required to
perform peering.
3.4.2. Responsibilities in Operating an X.400 Organizational MTA
ESnet will provide PRMD service to the ESnet community. ESnet will
peer with the other PRMDs in the International X.400 service and
provide a WEP for the ESnet community. An Organization/site needs to
decide if they are going to comply with the above PRMD requirements
or act as an organization associated to the ESnet PRMD. Minimally,
an organizational MTA will only have to support one of the protocol
stacks provided by it associated PRMD. But in all cases, the site
will need to provide a WEP and register/list their MTA(s) with ESnet.
3.5. Services Provided by ESnet
ESnet will provide PRMD service to those members of the ESnet
community who desire it. ESnet will peer with other PRMDs in the
International community (e.g. XNREN, Hughes Air Craft, NASA, CDC) and
provide a WEP for the ESnet community; the intent is to provide the
fullest PRMD level X.400 services.
ESnet will deploy two, PRMD level, X.400 MTAs in geographically
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.
3.5.5. Registering/Listing your PRMD or Organizational MTA with ESnet
To provide for the connection and routing requirements in X.400 you
will need to register/list your MTA with ESnet. This information
will be maintained in tables on the ESnet Information Server. ESnet
will also maintain information on the International X.400 service.
ESnet will use the same format for information as maintained by the
International X.400 service. This is described in detail in a IETF
X.400 operations paper "Routing Coordination for X.400 MHS Services
within a Multiprotocol/Multinetwork Environment". This paper is a
working draft, see Appendix G. It describes a machine independent
form for distribution of X.400 information.
There are three tables that must be maintained and exchanged by the
top level WEPS.
1. The Community Document
2. The WEP Document
3. The Domain Document
ESnet will submit these documents to the International X.400
community on behalf of the ESnet Community. If an ESnet PRMD wishes
to peer with the International PRMDs they will need to submit these
documents to that community.
The Community document is used to list the central coordination point
and file server where all MHS documents will be stored. It also
lists the communication stacks used by the MHS community. This
document will be submitted to the International X.400 service by
ESnet for the ESnet Community. ESnet PRMDs and Organizations do not
need to submit this form to ESnet. If an ESnet PRMD wishes to peer
with the International X.400 service then they must submit this form
to that community.
Each ESnet MHS domain will need to submit a WEP and Domain Document
to ESnet. The WEP document is used to list the WEPs used by an ESnet
MHS domain. It will contain all the information that is needed for
MTA connection and access control. ESnet will submit the ESnet
community WEP and Domain Documents to the International X.400
service. The WEP document consists of a list of WEPs, with the
following information for each one:
o The MTA Name
o Password
o Which MTS supported
o Which standard, 84 and/or 88
o Connection information outbound
o Connection information inbound
o Computer system information
o Point of contact
The Domain Document specifies all the X.400 domains managed by a
site. It indicates the person responsible and which WEP services
which Domain. This document contains the following information
repeated for each Domain:
o X.400 Domain
o Point of Contact
o Relaying WEP(s)
3.6. X.400 Message Routing Between ADMDS and PRMDS
While ESnet will provide X.400 routing service for systems, it cannot
provide routing via commercial X.400 carriers at this time. The
FTS-2000 charge for routing X.400 messages is $.45 (US) plus X.25
packet charges. This could result in a charge of several dollars for
large messages, a real possibility with the multi-media capacity of
X.400. The payment of this fee is not within the charter of ESnet
and the provision of a charging mechanism to charge member sites is
not currently contemplated.
3.7. X.400 Registration Requirements
It is recommended by the CCITT that all X.400 PRMD names be
nationally unique. This is a current CCITT agreement and allows
direct PRMD-PRMD peer routing. Since national uniqueness is
required, registration should be performed through an appropriate
registration authority (such as ANSI).
X.400 organization names must be unique within a PRMD. There is no
need for national uniqueness. Registration of an X.400 organization
name should be conducted through the PRMD operator.
The registration of X.400 names below the organization level are
usually a local matter. Uniqueness within the context of a superior
name should always be maintained.
See Section 4 for a more complete description of OSI registration
issues and procedures.
3.8. Future X.400 Issues to be Considered
3.8.1. X.400 Mail Routing to International DOE Researchers
Currently there are DOE researchers located in Switzerland, Japan,
Germany, China and Brazil. PRMD level connectivity to these
international locations does not exist presently. Since ESnet is not
chartered to pay for commercial X.400 services on behalf of the ESnet
community, "buying" this service is not a viable option.
There are efforts taking place to provide international X.400 service
over the (international) Internet. Once this becomes fully
operational, further research will have to be performed to see if
this provides the X.400 connectivity needed to support the DOE
researchers located abroad.
3.8.2. X.400 (1984) and X.400 (1988)
The ESnet MTAs will initially support the 1984 version of the X.400
standard. As the use of 1988 X.400 becomes more prevalent, support
for the newer standard will need to be addressed. One important
point, once the ESnet MTAs become 1988 X.400 compliant, they will
also have so support "downgrading" to 1984 X.400 to ensure reliable
X.400 mail delivery to the ESnet community.
3.8.3. X.400 Interaction with X.500
This is discussed in Section 2.10.2.
4. OSI Name Registration and Issues
Implementing OSI services requires that certain information objects
(e.g., people, information processing systems and applications) must
be unambiguously identifiable on a global basis. These objects may
be defined by a variety of organizations, e.g., ISO/IEC, CCITT,
commercial, and government.
To meet this requirement ISO/IEC and CCITT have established a
hierarchical structure of names (a tree). The top level of the
naming tree, shared by ISO and CCITT, represents the global naming-
domain. Naming domains are managed by registration authorities. A
registration authority can delegate authority for part of its
naming-domain to another (lower level) registration authority, thus
forming the tree.
Each object can be given a unique and unambiguous name by registering
the object's name with an OSI registration authority at an
appropriate level in the naming tree.
OSI name registration authorities and their procedures are expected
to change over time. Since names are intended to be stable, these
changes (hopefully!) will have minimal impact on existing OSI name
registrations.
This section describes the role of OSI registration authorities, the
difference between a "registration" and a "notification", and sources
of nationally unique names. Information about three OSI name
registration authorities; the American National Standards Institute
(ANSI), the General Services Administration (GSA), and the U.S.
Department of Energy (U.S. DOE); are given.
Registration of a name often requires stating a "right" to that name.
However, an OSI name registration does not guarantee legal name
rights. Name rights should be reviewed by legal experts prior to
registration. Information about the U.S. Department of Commerce,
Patent and Trademark Office (PTO) (potentially useful in asserting or
defending name rights) is given below.
4.1. Registration Authorities
OSI names are obtained through OSI name registration authorities by a
registration process. The selection of which particular registration
authority to use is determined by the desired level of the OSI name
in the naming hierarchy, possible restrictions on the names allocated
by each registration authority, and the applicability rules (will
they service your request) of each registration authority.
An OSI name registration authority allocates OSI names from the
particular naming-domain it controls. Every registration authority
can trace its naming authority to its parent registration authority,
and ultimately to the top (global) level of the naming hierarchy.
4.2. Registration Versus Notification
Registering an OSI name guarantees its uniqueness and lack of
ambiguity. For a name to be useful however, other parties (besides
the registration authority) will need to be notified of the name and
its usage.
There is a clear distinction between registration (obtaining an OSI
name) and notification (informing others of a name and its use).
Often the term "registration" is used to describe both activities,
this is a potential source of confusion.
For example, NADF and PSI (see Section 2) are not OSI registration
authorities. NADF may operate state registration authorities in the
future, if delegated that administrative right by the states. PSI
operates an X.500 pilot project and needs to be notified of
registered names when organizations join their pilot.
X.400 ADMD operators are also not OSI registration authorities,
although they accept notification of X.400 PRMD names used by their
customers.
The PTO is not an OSI registration authority. PTO names have no
meaning in an OSI context.
4.3. Sources of Nationally Unique Name Registration
There are four potential sources of nationally unique names which are
of interest to the ESnet community. These are ANSI, GSA, U.S. DOE
and the states. An overview of the ANSI, GSA, and U.S. DOE
procedures are given in later sections.
In order to maintain national uniqueness "constructed name syntax" is
used by GSA, U.S. DOE, and the states. The form of each name is
shown below, "name" is the name presented to the registration
authority for registration.
1. ANSI names are of the form "name".
2. GSA names are of the form "GOV+name".
3. U.S. DOE names are of the form "GOV+USDOE+name".
4. State names are of the form "CA+name" (using California).
State name registration authorities are not in operation at this
time. The use of U.S. DOE as a nationally unique name registration
source is not recommended due to the awkwardness of a double
constructed name.
4.4. How to Apply for ANSI Organization Names
ANSI is the root U.S. source of OSI recognized nationally unique
organization names. ANSI registration costs $2500 and results in
both an alphanumeric name and an associated numeric name. These
names may be used for a variety of purposes in X.400, X.500, and
other OSI services.
For ANSI OSI organization name registration forms and instructions,
you should send your request to:
American National Standards Institute, Inc.
Attn: Beth Somerville
OSI Registration Coordinator
11 West 42nd Street
New York, NY 10036
Phone: (212) 642-4976
ANSI registration procedures include a 90 day public review period
during which name requests can be easily challenged.
There is a mechanism to forward ANSI requests to the GSA, it is
discussed in the GSA section below.
4.5. How to Apply for GSA Organization Names
GSA is the registration authority for government use of GOSIP, their
registration services are free for federal government organizations.
Names assigned by GSA always begin with the characters "GOV+" and are
limited to 16 characters. By agreement with ANSI, these GSA assigned
names are national unique.
For GSA OSI Organization Name registration forms and instructions,
you should send your request to:
General Services Administration
Office of Telecommunications Services
Registration Services, Room 1221-L KBA
18th and F Streets, N.W.
Washington, D.C. 20405
4.5.1. GSA Designated Agency Representatives
When preparing the GSA registration form a designated agency
representative must sign where it says "Registration Official Name
and Signature". GSA will refuse requests missing this signature.
The GSA designated Agency Representative for the Department of Energy
is:
Steve Hackman
Electronics Engineer
U.S. Department of Energy
AD-241.3/GTN
Washington, D.C. 20585
Office Phone: (301) 903-6111
Office FAX: (301) 903-4125
E-Mail: hackman@gosip.xosi.doe.gov
4.5.2. Forwarding of ANSI Registrations to GSA
ANSI registration requests can be forwarded automatically to the GSA.
This is the equivalent of registering with both ANSI and GSA. The
result is two nationally unique OSI name registrations, "name" from
ANSI and "GOV+name" from GSA.
There is no GOSIP requirement for GSA registration but many feel the
additional GSA registration may be useful.
Assuming your organization is a federal government organization,
answer the last three questions on the ANSI registration form as
shown below:
1. Do you wish the information supplied in the request to remain
confidential? NO.
2. Do you wish to have your organization name registered with the
U.S. GOSIP Registration Authority (a.k.a. GSA)? YES.
3. Is your organization an organization of the Federal Government?
YES.
You must indicate on the application form the approval of the GSA
designated agency representative (Steve Hackman). He does not sign
as "Signature of Requestor", but some notation of his approval must
be attached or GSA will reject the forwarded application.
4.6. How to Apply for U.S. DOE Organization Names
ESnet sites are encouraged to review the DOE GOSIP procedures and
guidelines in planning their GOSIP activities. This document does
not conflict with current DOE GOSIP policies.
DOE can assign nationally unique names which are prefixed by the
string "GOV+USDOE+". Use of this name source is not recommended;
there is no apparent advantage in using U.S. DOE over GSA as a source
of nationally unique names.
Copies of current U.S. DOE GOSIP policies, guidelines, and
registration forms may be obtained through site DOE naming
authorities or Steve Hackman.
4.7. Why Apply for a Trademark with the PTO?
Legal issues may arise concerning the rights to use a desired name.
OSI name registrations are not intended to "legally protect" name
usage rights; that is not their function.
Consultation with legal experts concerning the rights to use a name
being registered is strongly advised, this recommendation does not
offer specific legal guidance. Applying for a trademark may be
considered as a means to assert or protect the rights to a name.
Per the PTO trademark application instructions there may be several
benefits in obtaining a trademark.
o The filing date of the application is a constructive date of
first use of the mark in commerce (this gives registrant
nationwide priority as of the date).
o The right to sue in Federal court for trademark infringement.
o Constructive notice of claim of ownership.
o Limited grounds for attacking a registration once it is five
years old.
4.8. How to Apply for a Trademark with the PTO
You should obtain a trademark application and detailed instructions
from the U.S. Department of Commerce, Patent and Trademark Office.
This can be done by mailing your request to the address below, or
calling the PTO at the phone number below:
U.S. Department of Commerce
Patent and Trademark Office
Washington, D.C. 20231
Phone: (703) 557-INFO
NOTE: The following information is based on ESnet experience in
filing for a trademark based on prior use.
After you receive your application, you will need to perform the
following steps.
1. Complete the written application form. If you have more than
one name you are filing, you must complete a separate form for
each name.
2. Provide a black-and-white drawing of the mark. In the case
where there is no artwork, only text, the text must be
centered on the page in uppercase.
3. Provide a check in the amount of $175 (for each application)
made payable to the Commissioner of Patents and Trademarks.
4. Provide three specimens showing actual use of the mark on or
in connection with the goods or services.
The class of goods/services associated with this trademark must be
specified on the registration form. The currently defined classes of
services are:
35 Advertising and business.
36 Insurance and financial.
37 Construction and repair.
38 Communication.
39 Transportation and storage.
40 Material treatment.
41 Education and entertainment.
42 Miscellaneous.
So, for example, there could be two (or more) "ESnet" trademarks,
with each trademark associated with a different service class. Thus,
trademarks are not nationally unique.
Before submitting your form, you should see if your trademark is
already registered to someone else (for the service class you
specified). This is typically done by your legal department through
the PTO Trademark Search Library.
Since the PTO form is a legal document, you must involve your legal
department and the documents may only be signed by someone who is a
legally recognized representative of your organization. For example,
in applying for the service mark "ESnet", the "Applicant Name" was
"The Regents of the University of California", and the legally
recognized representative was Dr. John Nuckolls, the director of the
Lawrence Livermore National Laboratory.
4.9. Future Name Registration Issues to be Considered
4.9.1. ANSI Registered ADMD and PRMD Names
There are discussions in the ANSI and CCITT communities revolving
around the idea of having a formal registration of all ADMD and PRMD
Names (not just ANSI Organization Names). The ideas being exchanged
include having a separate ANSI national registry for these names, and
having to pay a periodic "license" fee. This is just in the idea
discussion phase now, but it may impact the cost of ANSI ADMD and
PRMD Name registration in the near future.
Glossary
AA - See ADMINISTRATIVE AUTHORITY.
ADDMD - See ADMINISTRATIVE DIRECTORY MANAGEMENT DOMAIN.
ADMD - See ADMINISTRATION MANAGEMENT DOMAIN.
ADMINISTRATION - An Administration denotes a public telecommunications
administration or other organization offering public
telecommunications services.
ADMINISTRATION MANAGEMENT DOMAIN - An Administrative Management Domain
(ADMD) is a management domain managed by an Administration;
generally one of the common carriers (e.g. AT&T, MCI, U.S. Sprint,
etc.).
ADMINISTRATIVE AUTHORITY - An entity which has administrative control
over all entries stored within a single Directory System Agent
(DSA).
ADMINISTRATIVE DIRECTORY MANAGEMENT DOMAIN - An Administrative Directory
Management Domain (ADDMD) is a Directory Management Domain (DMD)
which is managed by an administration.
AE - See APPLICATION ENTITY.
ALIAS - An entry of the class "alias" containing information used to
provide an alternative name for an object.
ANSI - The American National Standards Institute. ANSI is the official
representative of the United States to ISO.
AP - See APPLICATION PROCESS.
APPLICATION ENTITY - An application entity is the OSI portion of an
Application Process (AP).
APPLICATION LAYER - The application layer is the portion of an OSI
system ultimately responsible for managing communication between
application processes (APs).
APPLICATION PROCESS - An application process is an object executing in a
real system (computer).
APPLICATION SERVICE ELEMENT - An application service element (ASE) is
the building block of an application entity (AE). Each AE consists
of one or more service elements, as defined by its application
context.
ASE - See APPLICATION SERVICE ELEMENT.
ATTRIBUTE - An attribute is the information of a particular type
concerning an object and appearing in an entry describing that
object in the Directory Information base (DIB).
ATTRIBUTE TYPE - An attribute type is that component of an attribute
which indicates the class of information given by that attribute.
ATTRIBUTE VALUE - An attribute value is a particular instance of the
class of information indicated by an attribute type.
BASE ATTRIBUTE SET - A minimum set of attributes whose values
unambiguously identify a particular management domain.
BODY - The body of the IP-message is the information the user wishes to
communicate.
CCITT - An international standards making organization specializing in
international communications standards and chartered by the United
Nations. "CCITT" is a french acronym meaning the International
Telephone and Telegraph Consultative Committee.
CHAINING - Chaining is a mode of interaction optionally used by a
Directory System Agent (DSA) which cannot perform an operation
itself. The DSA chains by invoking the operation of another DSA
and then relaying the outcome to the original requestor.
CLNP - The OSI Connectionless Network Protocol. CLNP's use is required
by GOSIP.
CONTENT - The piece of information that the originating User Agent (UA)
wishes delivered to the recipient UA. For inter-personal messaging
(IPM) UAs, the content consists of either an IP message or an IPM-
status-report.
COOPERATING USER AGENT - A User Agent (UA) that cooperates with another
recipient's UA in order to facilitate the communication between
originator and recipient.
DAP - See DIRECTORY ACCESS PROTOCOL.
DELIVERY - The interaction by which the Message Transfer Agent (MTA)
transfers to a recipient User Agent (UA) the content of a message
plus the delivery envelope.
DELIVERY ENVELOPE - The envelope which contains the information related
to the delivery of the message.
DESCRIPTIVE NAME - A name that denotes one and only one user in the
Message Handling System (MHS).
DIB - See DIRECTORY INFORMATION BASE.
DIRECTORY - The Directory is a repository of information about objects
and which provides directory services to its users which allow
access to the information.
DIRECTORY ACCESS PROTOCOL - The Directory Access Protocol (DAP) is the
protocol used between a Directory user Agent (DUA) and a Directory
System Agent (DSA).
DIRECTORY ENTRY - A Directory Entry is a part of the Directory
Information Base (DIB) which contains information about an object.
DIRECTORY INFORMATION BASE - The Directory Information Base (DIB) is the
complete set of information to which the Directory provides access
and which includes all pieces of information which can be read or
manipulated using the operations of the Directory.
DIRECTORY INFORMATION TREE - The Directory Information Tree (DIT) is the
Directory Information Base (DIB), considered as a tree, whose
vertices (other than the root) are the Directory entries.
DIRECTORY MANAGEMENT DOMAIN - A Directory Management Domain (DMD) is a
collection of one or more Directory System Agents (DSAs) and zero
or more Directory User Agents (DUAs) which is managed by a single
organization.
DIRECTORY SYSTEM AGENT - A Directory System Agent (DSA) is an OSI
application process which is part of the Directory.
DIRECTORY SYSTEM PROTOCOL - The Directory System Protocol (DSP) is the
protocol used between two Directory System Agents (DSAs).
DIRECTORY USER - A Directory user is the entity or person that accesses
the Directory.
DIRECTORY USER AGENT - A Directory User Agent (DUA) is an OSI
application process which represents the user in accessing the
Directory.
DISTINGUISHED NAME - The distinguished name of a given object is the
sequence of relative distinguished names (RDNs) of an entry which
represents the object and those of all of its superior entries (in
descending order).
DIT - See DIRECTORY INFORMATION TREE.
DMD - See DIRECTORY MANAGEMENT DOMAIN.
DN - See DISTINGUISHED NAME.
DNS - See DOMAIN NAME SERVICE.
DOMAIN NAME SERVICE - A hierarchical, distributed naming service
currently used in the Internet. DNS names typically take the form
of <machine.site.domain>, where <.domain> may be ".COM", ".EDU",
".GOV", ".MIL", ".NET", ".ORG" or ".<country-code>".
DSA - See DIRECTORY SYSTEM AGENT.
DSP - See DIRECTORY SYSTEM PROTOCOL.
DUA - See DIRECTORY USER AGENT.
ENCODED INFORMATION TYPE - It is the code and format of information that
appears in the body of an IP-message (examples of coded information
types are Telex, TIFO (Group 4 Facsimile), and voice).
ENVELOPE - A place in which the information to be used in the
submission, delivery and relaying of a message is contained.
FIPS - Federal Information Processing Standard. FIPS are produced by
NIST and specify a standard for the federal government, most FIPS
reference other formal standards from ANSI, IEEE, ISO or CCITT.
GOSIP - The Government Open System Interconnection (OSI) Profile. GOSIP
is a FIPS which defines the elements of OSI to be required by
government purchasers and how those elements should be implemented.
GOSIP is based on OSI standards and OIW implementor's agreements.
HEADING - The heading of an IP-message is the control information that
characterizes an IP-message.
INTERPERSONAL MESSAGING - Interpersonal Messaging (IPM) is communication
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
elements by: (1) interacting with originating User Agents (UAs)
via the submission dialogue, (2) relaying messages to other MTAs
based upon recipient designations, and (3) interacting with
recipient UAs via the delivery dialogue.
MESSAGE TRANSFER AGENT ENTITY - The Message Transfer Agent Entity (MTAE)
is an entity, located in an MTA, that is responsible for
controlling the Message Transfer Layer (MTL). It controls the
operation of the protocol to other peer entities in the MTL.
MESSAGE TRANSFER LAYER - The Message Transfer Layer (MTL) is a layer in
the Application layer that provides Message Transfer System (MTS)
service elements. These services are provided by means of the
services of the layer below plus the functionality of the entities
in the layer, namely the Message Transfer Agent Entities (MTAEs)
and the Submission and Delivery Entities (SDEs).
MESSAGE TRANSFER PROTOCOL - The Message Transfer Protocol (P1) is the
protocol which defines the relaying of messages between Message
Transfer Agents (MTAs) and other interactions necessary to provide
Message Transfer layer (MTL) services.
MESSAGE TRANSFER SERVICE - The Message Transfer Service is the set of
optional service elements provided by the Message Transfer System
(MTS).