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

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

MESSAGE TRANSFER SYSTEM - The Message Transfer System (MTS) is the
     collection of Message Transfer Agents (MTAs), which provide the
     Message Transfer Service elements.

MHS - See MESSAGE HANDLING SYSTEM.

MTA - See MESSAGE TRANSFER AGENT.

MTAE - See MESSAGE TRANSFER AGENT ENTITY.

MTL - See MESSAGE TRANSFER LAYER.

MTS - See MESSAGE TRANSFER SYSTEM.

MULTICASTING - Multicasting is a mode of interaction which may
     optionally be used by a Directory System Agent (DSA) which cannot
     perform an operation itself.  The DSA multicasts the operation
     (i.e. it invokes the operation of several other DSAs (in series or
     in parallel) and passes an appropriate outcome to the original
     requestor).

NAME - A name is a construct that singles out a particular object from

     all other objects.  A name must be unambiguous (i.e. denote just
     one object); however, it need not be unique (i.e. be the only name
     which unambiguously denotes the object).

NIST - The national institute of standards, a government organization
     which develops, endorses, and promulgates standards for use by the
     U.S.  government.

O/R ADDRESS - See ORIGINATOR/RECIPIENT ADDRESS.

O/R NAME - See ORIGINATOR/RECIPIENT NAME.

OBJECT (OF INTEREST) - Anything in some "world", generally the world of
     telecommunications and information processing or some part thereof,
     which is identifiable (i.e. can be named), and which it is of
     interest to hold information on in the Directory Information Base
     (DIB).

OIW - The OSI Implementors workshop.  OIW is one of three regional
     workshops (OIW, EWOS, AOW), which specifies implementation
     agreements for base OSI standards.  OIW's participants are mostly
     from the Americas and the OIW is jointly sponsored by the IEEE
     (Institute of Electrical and Electronic Engineers) and NIST.

OPEN SYSTEMS INTERCONNECTION - A term referring to the capability of
     interconnecting different systems.

ORIGINATING USER AGENT - The Originating User Agent (UA) is a UA that
     submits to the Message Transfer System (MTS) a message to be
     transferred.

ORIGINATOR - A user, a human being or computer process, from whom the
     Message Handling System (MHS) accepts a message.

ORIGINATOR/RECIPIENT ADDRESS - A descriptive name for a User Agent (UA)
     that contains certain characteristics which help the Message
     Transfer System (MTS) to locate the UA's point of attachment.  An
     Originator/Recipient (O/R) address is a type of O/R name.

ORIGINATOR/RECIPIENT NAME - The Originator/Recipient Name (O/R Name) is
     the descriptive name for a User Agent (UA).

OSI - See OPEN SYSTEMS INTERCONNECTION.

PRDMD - See PRIVATE DIRECTORY MANAGEMENT DOMAIN.

PRIMITIVE NAME - A name assigned by a naming authority.  Primitive names
     are components of descriptive names.

PRIVATE DIRECTORY MANAGEMENT DOMAIN - A Private Directory Management
     Domain (PRDMD) is a Directory Management Domain which is managed by
     an organization other than an administration.

PRIVATE MANAGEMENT DOMAIN - A Private Management Domain (PRMD) is a
     management domain managed by a company or non-commercial
     organization.

PRMD - See PRIVATE MANAGEMENT DOMAIN.

RDN - See RELATIVE DISTINGUISHED NAME.

RECIPIENT - A user, a human being or computer process, who receives a
     message from the Message Handling System (MHS).

RECIPIENT USER AGENT - A User Agent (UA) to which a message is delivered
     or that is specified for delivery.

REFERRAL - A referral is an outcome which can be returned by a Directory
     System Agent (DSA) which cannot perform an operation itself, and
     which identifies one or more other DSAs more able to perform the
     operation.

RELATIVE DISTINGUISHED NAME - A Relative Distinguished Name (RDN) is a
     set of attribute value assertions, each of which is true,
     concerning the distinguished values of a particular entry.

RELAYING - The interaction by which one Message Transfer Agent (MTA)
     transfers to another MTA the content of a message plus the relaying
     envelope.

RELAYING ENVELOPE - The envelope which contains the information related
     to the operation of the Message Transfer System (MTS) plus the
     service elements requested by the originating User Agent (UA).

RFC - Request for Comments.  The RFC's are documents used to propose or
     specify internet community standards.

ROOT - The vertex that is not the final vertex of any arc is referred to
     as the root vertex (or informally as the root) of the tree.

SCHEMA - The Directory Schema is the set of rules and constraints
     concerning the Directory Information Tree (DIT) structure, object
     class definitions, attribute types, and syntaxes which characterize
     the Directory Information base (DIB).

SDE - See SUBMISSION AND DELIVERY ENTITY.

SMTP - Simple Mail Transfer Protocol.  An e-mail protocol frequently
     used by the Internet community.

SUBMISSION - The interaction by which an originating User Agent (UA)
     transfers to a Message Transfer Agent (MTA) the contents of a
     message plus the submission envelope.

SUBMISSION AND DELIVERY ENTITY - The Submission and Delivery Entity
     (SDE) is an entity located in the Message Transfer Layer (MTL),
     co-resident with a User Agent (UA) and not with a Message Transfer
     Agent (MTA), and responsible for controlling the submission and
     delivery interactions with a Message Transfer Agent Entity (MTAE).

SUBMISSION AND DELIVERY PROTOCOL - The Submission and Delivery Protocol
     (P3) is the protocol which governs communication between a
     Submission and Delivery Entity (SDE) and a Message Transfer Agent
     Entity (MTAE).

SUBMISSION ENVELOPE - The envelope which contains the information the
     Message Transfer System (MTS) requires to provide the requested
     service elements.

TCP - A non-OSI transport protocol, the Transmission Control Protocol,
     used extensively in the Internet.  TP4 is the OSI alternative to
     TCP.

TP0 - An OSI transport protocol specified by GOSIP and generally used
     with connection-oriented networks.

TP4 - An OSI transport protocol specified by GOSIP and generally used
     with connectionless networks such as CLNP.

TREE - A tree is a set of points (vertices), and a set of directed lines
     (arcs); each arc leads from a vertex V to a vertex V'.  The
     vertices V and V' are said to be the initial and final vertices of
     an arc a from V to V'.  In a tree, several different arcs may have
     the same initial vertex, but not the same final vertex.

UA - See USER AGENT.

UAE - See USER AGENT ENTITY.

UAL - See USER AGENT LAYER.

USER - A person or computer application or process who makes use of a
     Message Handling System (MHS).

USER AGENT - Typically, the User Agent (UA) is a set of computer

     processes (for example, an editor, a file system, a word processor)
     that are used to create, inspect, and manage the storage of
     messages.  There is typically one user per User Agent (UA).  During
     message preparation, the originator communicates with his UA via an
     input/output (I/O) device (for example, a keyboard, display,
     printer, facsimile machine, and/or telephone).  Also by means of
     these devices, the UA communicates to its user messages received
     from the Message Transfer System (MTS).  To send and receive
     messages, the UA interacts with the MTS via the submission and
     delivery protocol.

USER AGENT ENTITY - A User Agent Entity (UAE) is an entity in the User
     Agent Layer (UAL) of the Application Layer that controls the
     protocol associated with cooperating UAL services.  It exchanges
     control information with the Message Transfer Agent Entity (MTAE)
     or the Submission and Delivery Entity (SDE) in the layer below.
     The control information is the information the Message Transfer
     layer (MTL) requires to create the appropriate envelope and thus
     provide the desired message transfer service elements.

USER AGENT LAYER - The User Agent Layer (UAL) is the layer that contains
     the User Agent Entities (UAEs).

X.25 - A packet switched network standard often used by public providers
     and optional in GOSIP.

Appendix A:  Current Activities in X.500

   NOTE:  The following are edited excerpts from the IETF Directory
   Services Monthly reports as well as a few IETF scope documents.
   Effort has been taken to make sure this information is current as of
   late 1991.  At the end of each section are lists of anonymous FTP
   and/or an e-mail address if more information is desired.

                                 IETF DISI
       (Directory Information Services Infrastructure Working Group)

   The Directory Information Services (pilot) Infrastructure Working
   Group is chartered to facilitate the deployment in the Internet of
   Directory Services based on implementations of the X.500 standards.
   It will facilitate this deployment by producing informational RFCs
   intended to serve as a Directory Services "Administrator's Guide".
   These RFCs will relate the current usage and scope of the X.500
   standard and Directory Services in North America and the world, and
   will contain information on the procurement, installation, and
   operation of various implementations of the X.500 standard.  As the
   various implementations of the X.500 standard work equally well over
   TCP/IP and CLNP, the DISI working group shall not mandate specific

   implementations or transport protocols.

   DISI is an offshoot of the OSI Directory Services group, and,
   accordingly, is a combined effort of the OSI Integration Area and
   User Services Area of the IETF.  The current OSIDS working group was
   chartered to smooth out technical differences in information storage
   schema and difficulties in the interoperability and coherence of
   various X.500 implementations.  The DISI group is concerned solely
   with expanding the Directory Services infrastructure.  As DISI will
   be providing information to facilitate the building of infrastructure
   with an eye towards truly operational status, DISI will need to form
   liaisons with COSINE, PARADISE, and perhaps the RARE WG3.

   As a final document, the DISI working group shall write a charter for
   a new working group concerned with user services, integration,
   maintenance and operations of Directory Services, the Operations and
   Infrastructure of Directory Services (OIDS) Group.

   One particular DISI document you may be interested in is a catalogue
   of the various X.500 implementations:

      Title     : Catalog of Available X.500 Implementations
      Author(s) : R. Lang, R. Wright
      Filename  : rfc1292.txt
      Pages     : 103

   This document is available on the ESnet Information Server in the
   [ANONYMOUS.RFCS] directory.

   Mailing list address:
      General Discussion:  disi@merit.edu
      To Subscribe:        disi-request@merit.edu
   Anonymous FTP site address:  (e-mail archive is here)
      merit.edu

             IETF OSI-DS (OSI Directory Service Working Group)

   The OSI-DS group works on issues relating to building an OSI
   Directory Service using X.500 and its deployment on the Internet.
   Whilst this group is not directly concerned with piloting, the focus
   is practical, and technical work needed as a pre-requisite to
   deployment of an open Directory will be considered.

   The major goal of this WG is to provide the technical framework for a
   Directory Service infrastructure on the Internet.  This
   infrastructure should be based on the OSI Directory (X.500).  It is
   intended that this infrastructure can be used by many applications.
   Whilst this WG is not directly concerned with operation of services,

   close liaison is expected with those groups which do operate pilots
   and services.

   Liaisons have been established with RARE WG3, NIST, CCITT/ISO IEC,
   North American Directory Forum.

   X.500 (1984) / ISO 9594 does not have sufficient functionality for
   full deployment on the Internet.  This group identifies areas where
   extensions are required.

   It is a basic aim of the group to be aligned to appropriate base
   standards and functional standards.  Any activity should be
   undertaken in the light of ongoing standardization activity.  Areas
   which should be examined include:

   o  Replication

   o  Knowledge Representation

   o  Schema Management

   o  Access Control

   o  Authentication

   o  Distributed operations for partially connected DSAs

   o  Presentation Address Handling

   Mailing list address:
      General Discussion:  osi-ds@cs.ucl.ac.uk
      To Subscribe:        osi-ds-request@cs.ucl.ac.uk
   Anonymous FTP site address:  (all OSI-DS documents and e-mail archive
      cs.ucl.ac.uk               are here)

                   FOX (Field Operational X.500 Project)

   The FOX project is a DARPA funded effort to provide a basis for
   operational X.500 deployment in the NREN/Internet.  This work is
   being carried out at Merit, NYSERnet/PSI, SRI and ISI.  ISI is the
   main contractor and responsible for project oversight.

   There are two primary thrusts of the FOX project:

   1.  X.500 Infrastructure:  It is important that multiple
       interoperable platforms be available for deployment.  FOX
       plans to examine and test the interoperability of the QUIPU
       and NIST-X.500 (Custos) implementations, and DNANS-X.500 if

       possible.  In addition, FOX will explore X.500 interfaces to
       conventional database systems (one target is Sybase), an
       alternate OS platform (VM) for X.500 servers, and X-window
       based user interfaces.

   2.  X.500 Applications:  A long-range goal is to facilitate the
       use of X.500 for real Internet applications.  FOX will first
       focus on making network infrastructure information available
       through X.500.  This includes network and AS site contacts,
       topology information, and the NIC WHOIS service.

   A centrally managed X.500 version will be the first phase of a WHOIS
   service.  Providing an X.500 version of a well-known widely-used
   service should promote the use of X.500 by Internet users.  In
   addition, this effort will provide experience in designing X.500
   applications.  However, the manageability of this scheme will be
   short-lived, so the next step will be a design for a distributed
   version of WHOIS.

   Finally, it is critical for Internet X.500 efforts to be aligned with
   directory service efforts that are ongoing in other communities.  FOX
   participants are involved in, or are otherwise tracking these
   efforts, and information about FOX activities will be publicly
   available.

                   NADF (North American Directory Forum)

   The North American Directory Forum (NADF) is a collection of
   organizations which offer, or plan to offer, public Directory
   services in North America, based on the CCITT X.500 Recommendations.

   The NADF has produced a document, NADF-175, "A Naming Scheme for
   c=US", which has been issued as RFC-1255.

   The NADF-175 document proposes the use of existing civil
   infrastructure for naming objects under c=US.  This has the advantage
   of using existing registration authorities and not establishing any
   new ones (the document simply maps names assigned by existing
   authorities into different portions of the c=US DIT).  The document
   is intended as the basis for X.500 names in the U.S. for the long-
   term; it is important that interested parties get a copy, review it,
   and return comments.

   A second output, which is still undergoing development, is NADF-128,
   a preliminary draft on "Mapping the DIT onto Multiple ADDMDs".  This
   describes how the c=US portion of the DIT is mapped onto DSAs and
   what service-providers must minimally share in order to achieve a
   working public directory.  The next revision of this document will

   likely be ASCII-ized and published as an informational RFC.

           NIST (National Institute of Standards and Technology)

   NIST is involved in several X.500 activities:  standards, pilot
   deployment, and development of an X.500 implementation, Custos.  The
   objective is to see X.500 widely deployed and used in the U.S.
   Government.  X.500 is expected to be in the next release of the U.S.
   Government OSI Profile (GOSIP).  In the standards efforts, emphasis
   is on access control and replication; the other activities are
   described in some detail below.

   o  NIST/GSA X.500 Pilot Deployment:  NIST and GSA are
      collaborating in the creation of a U.S. Government X.500 pilot
      deployment.  To date, two meetings have been held.  At the
      second, held on April 25th at NIST, significant progress was
      made towards refining an initial draft schema developed by
      NIST.  A number of government agency requirements will be
      included in the next schema revision.  Once the schema is
      defined, agencies will begin collecting data for loading into
      the directory.  Initially, NIST will offer to host agency data
      on Custos DSAs running at NIST.  Eventually, agencies are
      expected to obtain and operate DSAs.

   o  CUSTOS:  The NIST X.500 public-domain implementation, Custos,
      is implemented on ISODE, although it otherwise bears no
      relation to QUIPU.  One of its more interesting features is that
      the DBMS interface is SQL, and we provide a simple DBMS as part
      of Custos to support the DSA.  Information can be optionally
      loaded into memory, and the memory usage is reasonably
      efficient on a per-entry basis.

                     OIW (OSI Implementor's Workshop)

   The OSI Implementor's Workshop (OIW) is an open public forum for
   technical issues, concerned with the timely development of
   implementation agreements based on emerging international OSI
   standards.  The Workshop accepts as input the specifications of
   emerging standards for protocols, and produces as output agreements
   on the implementation and testing particulars of these protocols.
   This process is expected to expedite the development of OSI protocols
   and to promote interoperability of independently manufactured data
   communications equipment.

   The Workshop organizes its work through Special Interest Groups
   (SIGs) that prepare technical documentation.  The SIGs are encouraged
   to coordinate with standards organizations and user groups, and to
   seek widespread technical consensus on implementation agreements

   through international discussions and liaison activities.

   The Directory SIG of the Workshop produces agreements on the
   implementation of Directory protocols based on ISO 9594 and CCITT
   X.500 Recommendations.  There are three major areas that the SIG is
   working on for 1991:  access control, replication, and distributed
   operations.

   Mailing list address:
      General Discussion:  dssig@nisc.sri.com
      To Subscribe:        dssig-request@nisc.sri.com

                             PARADISE Project

   The PARADISE project is based at the Department of Computer Science,
   University College London (UCL).

   PARADISE is a sub-project of the broader COSINE project sponsored
   under the umbrella of EUREKA by eighteen participating countries and
   aimed at promoting OSI to the academic, industrial and governmental
   research and development organizations in Europe.  The countries
   involved are those of the EC, EFTA plus Yugoslavia; that is:
   Austria, Belgium, Denmark, Finland, France, Germany, Greece, Holland,
   Ireland, Italy, Luxembourg, Norway, Portugal, Spain, Sweden,
   Switzerland, United Kingdom, and Yugoslavia.

   The partners funded by PARADISE besides UCL are:

   o  The Networks Group at the University of London Computer Centre
      (ULCC), which is a service-oriented organization providing a
      range of facilities to the academic community in London and the
      entry point into the UK for IXI, the COSINE international X.25
      backbone;

   o  X-Tel Services Ltd, a software company based in Nottingham
      which currently provides service support to the UK Academic
      X.500 pilot; and

   o  PTT Telematic Systems from the Netherlands, which in turn has
      subcontracted the Swiss and Finnish PTTs, and whose involvement
      is to create a forum for discussion on X.500 among the European
      carrier administrations.

   The project also aims to have representation from all the
   participating countries, which in the majority of cases are the
   existing X.500 national pilots.

   Of the 18 countries involved, at least 12 are registered in the White

   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.