Difference between revisions of "RFC1330"

From RFC-Wiki
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
−
 
−
 
−
 
−
 
−
 
 
Network Working Group                        ESCC X.500/X.400 Task Force
 
Network Working Group                        ESCC X.500/X.400 Task Force
 
Request for Comments: 1330      ESnet Site Coordinating Committee (ESCC)
 
Request for Comments: 1330      ESnet Site Coordinating Committee (ESCC)
Line 14: Line 9:
 
                     within the ESnet Community
 
                     within the ESnet Community
  
−
Status of this Memo
+
'''Status of this Memo'''
 +
 
 
This memo provides information for the Internet community.  It does
 
This memo provides information for the Internet community.  It does
 
not specify an Internet standard.  Distribution of this memo is
 
not specify an Internet standard.  Distribution of this memo is
 
unlimited.
 
unlimited.
 +
 
Overview
 
Overview
 +
 
The Energy Sciences Network (ESnet) is a nation-wide computer data
 
The Energy Sciences Network (ESnet) is a nation-wide computer data
 
communications network managed and funded by the United States
 
communications network managed and funded by the United States
Line 28: Line 26:
 
programs, and provide widespread access to existing ER supercomputer
 
programs, and provide widespread access to existing ER supercomputer
 
facilities.
 
facilities.
 +
 
Coordination of ER-wide network-related technical activities over the
 
Coordination of ER-wide network-related technical activities over the
 
ESnet backbone is achieved through the ESnet Site Coordinating
 
ESnet backbone is achieved through the ESnet Site Coordinating
Line 38: Line 37:
 
makes recommendations to the ESnet community on how these services
 
makes recommendations to the ESnet community on how these services
 
should be deployed to meet the mission of DOE/OER.
 
should be deployed to meet the mission of DOE/OER.
 +
 
This RFC is a near verbatim copy of the whitepaper produced by the
 
This RFC is a near verbatim copy of the whitepaper produced by the
 
ESnet Site Coordinating Committee's X.500/X.400 Task Force.
 
ESnet Site Coordinating Committee's X.500/X.400 Task Force.
−
Table of Contents
 
−
Status of this Document  .......................................    4
 
−
Acknowledgments  ...............................................    4
 
  
 +
3.3.1  Participating in the ESnet Private Management Domain  ...  25
  
−
 
−
 
−
 
−
 
−
 
−
1  Introduction  ...............................................    5
 
−
1.1  Abstract and Introduction  ................................    5
 
−
1.2  Structure of this Document  ...............................    5
 
−
2  X.500 - OSI Directory Services  .............................    6
 
−
2.1  Brief Tutorial  ...........................................    6
 
−
2.2  Participation in the PSI White Pages Pilot Project  .......    7
 
−
2.3  Recommended X.500 Implementation  .........................    7
 
−
2.4  Naming Structure  .........................................    8
 
−
2.4.1  Implications of the Adoption of RFC-1255 by PSI  ........    9
 
−
2.4.2  Universities and Commercial Entities  ...................  10
 
−
2.4.3  Naming Structure Below the o=<site> Level  ..............  10
 
−
2.5  Information Stored in X.500  ..............................  13
 
−
2.5.1  Information Security  ...................................  14
 
−
2.6  Accessing the X.500 Directory Service  ....................  14
 
−
2.6.1  Directory Service via WHOIS  ............................  15
 
−
2.6.2  Directory Service via Electronic Mail  ..................  15
 
−
2.6.3  Directory Service via FINGER  ...........................  15
 
−
2.6.4  Directory Service via Specialized Applications  .........  15
 
−
2.6.5  Directory Service from PCs and MACs  ....................  16
 
−
2.7  Services Provided by ESnet  ...............................  16
 
−
2.7.1  X.500 Operations Mailing List  ..........................  17
 
−
2.7.2  Accessing the X.500 Directory  ..........................  17
 
−
2.7.3  Backbone Site Aliases  ..................................  18
 
−
2.7.4  Multiprotocol Stack Support  ............................  18
 
−
2.7.5  Managing a Site's X.500 Information  ....................  19
 
−
2.7.5.1  Open Availability of Site Information  ................  19
 
−
2.7.5.2  Access Methods for Local Users  .......................  19
 
−
2.7.5.3  Limitations of Using ESnet Services  ..................  20
 
−
2.8  ESnet Running a Level-0 DSA for c=US  .....................  20
 
−
2.9  X.500 Registration Requirements  ..........................  21
 
−
2.10  Future X.500 Issues to be Considered  ....................  21
 
−
2.10.1  ADDMDS Interoperating with PRDMDS  .....................  21
 
−
2.10.2  X.400 Interaction with X.500  ..........................  21
 
−
2.10.3  Use of X.500 for NIC Information  ......................  22
 
−
2.10.4  Use of X.500 for Non-White Pages Information  ..........  22
 
−
2.10.5  Introduction of New X.500 Implementations  .............  22
 
−
2.10.6  Interaction of X.500 and DECdns  .......................  22
 
−
3  X.400 - OSI Message Handling Services  ......................  23
 
−
3.1  Brief Tutorial  ...........................................  23
 
−
3.2  ESnet X.400 Logical Backbone  .............................  25
 
−
3.3  Naming Structure  .........................................  25
 
−
3.3.1  Participating in the ESnet Private Management Domain  ...  25
 
−
3.3.2  Operating a Site Private Management Domain  .............  26
 
−
3.3.3  Detailed Name Structure  ................................  26
 
−
3.4  X.400 Routing  ............................................  26
 
−
3.4.1  Responsibilities in Operating an X.400 PRMD MTA  ........  28
 
 
3.4.2  Responsibilities in Operating an X.400 Organizational MTA  29
 
3.4.2  Responsibilities in Operating an X.400 Organizational MTA  29
−
3.5  Services Provided by ESnet  ...............................  29
 
  
 +
3.5.5  Registering/Listing your PRMD or Organizational MTA with
  
 +
Appendix D:  Sample X.500 Input File and Restricted Character
  
−
 
−
 
−
 
−
 
−
3.5.1  X.400 Operations Mailing List  ..........................  30
 
−
3.5.2  MTA Routing Table on ESnet Information Server  ..........  30
 
−
3.5.3  MTA Routing Table Format  ...............................  30
 
−
3.5.4  Gateway Services and Multiprotocol Stack Support  .......  30
 
−
3.5.5  Registering/Listing your PRMD or Organizational MTA with
 
−
      ESnet  ..................................................  31
 
−
3.6  X.400 Message Routing Between ADMDS and PRMDS  ............  32
 
−
3.7  X.400 Registration Requirements  ..........................  32
 
−
3.8  Future X.400 Issues to be Considered  .....................  33
 
−
3.8.1  X.400 Mail Routing to International DOE Researchers  ....  33
 
−
3.8.2  X.400 (1984) and X.400 (1988)  ..........................  33
 
−
3.8.3  X.400 Interaction with X.500  ...........................  33
 
−
4  OSI Name Registration and Issues  ...........................  33
 
−
4.1  Registration Authorities  .................................  34
 
−
4.2  Registration Versus Notification  .........................  34
 
−
4.3  Sources of Nationally Unique Name Registration  ...........  35
 
−
4.4  How to Apply for ANSI Organization Names  .................  35
 
−
4.5  How to Apply for GSA Organization Names  ..................  36
 
−
4.5.1  GSA Designated Agency Representatives  ..................  36
 
−
4.5.2  Forwarding of ANSI Registrations to GSA  ................  37
 
−
4.6  How to Apply for U.S. DOE Organization Names  .............  37
 
−
4.7  Why Apply for a Trademark with the PTO?  ..................  38
 
−
4.8  How to Apply for a Trademark with the PTO  ................  38
 
−
4.9  Future Name Registration Issues to be Considered  .........  39
 
−
4.9.1  ANSI Registered ADMD and PRMD Names  ....................  39
 
−
Glossary  ......................................................  40
 
−
Appendix A:  Current Activities in X.500  ......................  49
 
−
Appendix B:  Current Activities in X.400  ......................  55
 
−
Appendix C:  How to Obtain QUIPU, PP and ISODE  ................  58
 
−
Appendix D:  Sample X.500 Input File and Restricted Character
 
−
            List  .............................................  65
 
−
Appendix E:  ESnet Backbone Sites  .............................  68
 
 
Appendix F:  Local Site Contacts for DOE Naming Authorities  ...  70
 
Appendix F:  Local Site Contacts for DOE Naming Authorities  ...  70
−
Appendix G:  Recommended Reading  ..............................  77
 
−
Appendix H:  Task Force Member Information  ....................  83
 
−
Security Considerations  .......................................  86
 
−
Authors' Addresses  ............................................  86
 
  
 +
            Recommendations for the Phase I Deployment of
 +
                OSI Directory Services (X.500) and
 +
                OSI Message Handling Services (X.400)
 +
                    within the ESnet Community
  
 +
      ESnet Site Coordinating Committee X.500/X.400 Task Force
  
 +
                            Version 1.1
  
 +
                            March 1992
  
 +
Status of this Document
  
 +
This document makes recommendations for the Phase I deployment of OSI
 +
Directory Services and OSI Message Handling Services within the ESnet
 +
Community.  This document is available via anonymous FTP on the ESnet
 +
Information Server (nic.es.net, 128.55.32.3) in the directory
 +
[ANONYMOUS.ESNET-DOC] in the file ESNET-X500-X400-VERSION-1-1.TXT.
 +
The distribution of this document is unlimited.
  
 +
Acknowledgments
  
−
 
+
The following individuals have participated in and contributed to the
−
 
 
−
 
 
−
 
 
−
 
 
−
 
 
−
 
 
−
 
 
−
 
 
−
 
 
−
            Recommendations for the Phase I Deployment of
 
−
                OSI Directory Services (X.500) and
 
−
                OSI Message Handling Services (X.400)
 
−
                    within the ESnet Community
 
−
      ESnet Site Coordinating Committee X.500/X.400 Task Force
 
−
                            Version 1.1
 
−
                            March 1992
 
−
Status of this Document
 
−
This document makes recommendations for the Phase I deployment of OSI
 
−
Directory Services and OSI Message Handling Services within the ESnet
 
−
Community.  This document is available via anonymous FTP on the ESnet
 
−
Information Server (nic.es.net, 128.55.32.3) in the directory
 
−
[ANONYMOUS.ESNET-DOC] in the file ESNET-X500-X400-VERSION-1-1.TXT.
 
−
The distribution of this document is unlimited.
 
−
Acknowledgments
 
−
The following individuals have participated in and contributed to the
 
 
ESCC X.500/X.400 Task Force.  Several of these individuals have also
 
ESCC X.500/X.400 Task Force.  Several of these individuals have also
 
authored portions of this document.  See Appendix H for additional
 
authored portions of this document.  See Appendix H for additional
 
information regarding task force members and contributing authors.
 
information regarding task force members and contributing authors.
 +
 
Allen Sturtevant (Chair)  Lawrence Livermore National Laboratory
 
Allen Sturtevant (Chair)  Lawrence Livermore National Laboratory
 
Bob Aiken                U.S. DOE/OER/SCS (now with NSF)
 
Bob Aiken                U.S. DOE/OER/SCS (now with NSF)
Line 201: Line 100:
 
Russ Wright              Lawrence Berkeley Laboratory
 
Russ Wright              Lawrence Berkeley Laboratory
  
 +
== Introduction ==
  
 +
=== Abstract and Introduction ===
  
−
 
−
 
−
 
−
 
−
==  Introduction ==
 
−
===  Abstract and Introduction ===
 
 
This document recommends an initial approach for the Phase I
 
This document recommends an initial approach for the Phase I
 
deployment of OSI Directory Services (X.500) and OSI Message Handling
 
deployment of OSI Directory Services (X.500) and OSI Message Handling
Line 214: Line 109:
 
directly connected ESnet backbone sites will participate and follow
 
directly connected ESnet backbone sites will participate and follow
 
the suggestions set forth in this document.
 
the suggestions set forth in this document.
 +
 
Section 7 of the "ESnet Program Plan" (DOE/OER-0486T, dated March
 
Section 7 of the "ESnet Program Plan" (DOE/OER-0486T, dated March
 
1991) cites the need for further research and investigation in the
 
1991) cites the need for further research and investigation in the
Line 226: Line 122:
 
services, a consistent transition path will be ensured and the
 
services, a consistent transition path will be ensured and the
 
services provided will be mutually valuable and useful.
 
services provided will be mutually valuable and useful.
 +
 
X.500 and X.400 are continuously evolving standards, and are
 
X.500 and X.400 are continuously evolving standards, and are
 
typically updated every four years.  U.S. GOSIP (Government OSI
 
typically updated every four years.  U.S. GOSIP (Government OSI
Line 237: Line 134:
 
sense, there isn't a specific "final phase" goal, but rather several
 
sense, there isn't a specific "final phase" goal, but rather several
 
new releases (updates) to the level of existing services.
 
new releases (updates) to the level of existing services.
−
=== Structure of this Document ===
+
 
 +
=== Structure of this Document ===
 +
 
 
X.500 is presented first.  The issues of DSA (Directory Service
 
X.500 is presented first.  The issues of DSA (Directory Service
 
Agent) deployment, DSA registration, naming schema, involvement in
 
Agent) deployment, DSA registration, naming schema, involvement in
Line 244: Line 143:
 
optimization, user friendly naming and update frequency are
 
optimization, user friendly naming and update frequency are
 
addressed.
 
addressed.
 +
 
In the area of X.400, issues relating to MTA (Message Transfer Agent)
 
In the area of X.400, issues relating to MTA (Message Transfer Agent)
 
deployment, ESnet X.400 well-known entry points, ESnet backbone site
 
deployment, ESnet X.400 well-known entry points, ESnet backbone site
Line 249: Line 149:
 
PRMD peering, bidirectional X.400-SMTP relaying and
 
PRMD peering, bidirectional X.400-SMTP relaying and
  
 +
private/commercial X.400 routing are discussed.
  
 +
Finally, the issues in name registration with ANSI (American National
 +
Standards Institute), GSA (General Services Administration) and the
 +
U.S. Department of Commerce, Patent and Trademark Office (PTO) are
 +
discussed.
  
 +
== X.500 - OSI Directory Services ==
  
 +
=== Brief Tutorial ===
  
−
 
−
 
−
private/commercial X.400 routing are discussed.
 
−
Finally, the issues in name registration with ANSI (American National
 
−
Standards Institute), GSA (General Services Administration) and the
 
−
U.S. Department of Commerce, Patent and Trademark Office (PTO) are
 
−
discussed.
 
−
==  X.500 - OSI Directory Services ==
 
−
===  Brief Tutorial ===
 
 
X.500 is a CCITT/ISO standard which defines a global solution for the
 
X.500 is a CCITT/ISO standard which defines a global solution for the
 
distribution and retrieval of information (directory service).  The
 
distribution and retrieval of information (directory service).  The
Line 272: Line 170:
 
nature of International standards, work continues on the 1992 X.500
 
nature of International standards, work continues on the 1992 X.500
 
standard agreements.
 
standard agreements.
 +
 
The Information Model specifies how information is defined in the
 
The Information Model specifies how information is defined in the
 
directory.  The Directory holds information objects, which contain
 
directory.  The Directory holds information objects, which contain
Line 296: Line 195:
 
each naming an arc in the path.  Therefore, a DN for an entry is
 
each naming an arc in the path.  Therefore, a DN for an entry is
 
built by tracing the path from the root of the DIT to the entry.
 
built by tracing the path from the root of the DIT to the entry.
 +
 
The Functional Model defines how the information is stored in the
 
The Functional Model defines how the information is stored in the
−
 
−
 
−
 
−
 
−
 
−
 
  
 
directory, and how users access the information.  There are two
 
directory, and how users access the information.  There are two
Line 310: Line 204:
 
particular subset of the Directory Information Tree and provides an
 
particular subset of the Directory Information Tree and provides an
 
access point to the Directory for a DUA.
 
access point to the Directory for a DUA.
 +
 
The Organizational Model of the OSI Directory describes the service
 
The Organizational Model of the OSI Directory describes the service
 
in terms of the policy defined between entities and the information
 
in terms of the policy defined between entities and the information
Line 315: Line 210:
 
A Directory Management Domain (DMD) consists of one or more DSAs,
 
A Directory Management Domain (DMD) consists of one or more DSAs,
 
which collectively hold and manage a portion of the DIT.
 
which collectively hold and manage a portion of the DIT.
 +
 
The Security Model defines two types of security for Directory data:
 
The Security Model defines two types of security for Directory data:
 
Simple Authentication (using passwords) and Strong Authentication
 
Simple Authentication (using passwords) and Strong Authentication
 
(using cryptographic keys).  Authentication techniques are invoked
 
(using cryptographic keys).  Authentication techniques are invoked
 
when a user or process attempts a Directory operation through a DUA.
 
when a user or process attempts a Directory operation through a DUA.
−
=== Participation in the PSI White Pages Pilot Project ===
+
 
 +
=== Participation in the PSI White Pages Pilot Project ===
 +
 
 
The PSI White Pages Pilot Project is currently the most well-
 
The PSI White Pages Pilot Project is currently the most well-
 
established X.500 pilot project within the United States.  For the
 
established X.500 pilot project within the United States.  For the
 
country=US portion of the DIT, PSI currently has over 80 organization
 
country=US portion of the DIT, PSI currently has over 80 organization
 
names registered.  Of these, several are ESnet-related.
 
names registered.  Of these, several are ESnet-related.
 +
 
The PSI White Pages Pilot Project is also connected to the Pilot
 
The PSI White Pages Pilot Project is also connected to the Pilot
 
International Directory Service, PARADISE.  This pilot project
 
International Directory Service, PARADISE.  This pilot project
Line 332: Line 231:
 
Yugoslavia.  The combined totals for all of these countries
 
Yugoslavia.  The combined totals for all of these countries
 
(including the United States) as of December 1991 are:
 
(including the United States) as of December 1991 are:
 +
 
                     DSAs:                    301
 
                     DSAs:                    301
 
                     Organizations:          2,132
 
                     Organizations:          2,132
 
                     White Pages Entries:  581,104
 
                     White Pages Entries:  581,104
 +
 
Considering the large degree of national, and international,
 
Considering the large degree of national, and international,
 
connectivity within the PSI White Pages Pilot Project, it is
 
connectivity within the PSI White Pages Pilot Project, it is
 
recommended that directly connected ESnet backbone sites join this
 
recommended that directly connected ESnet backbone sites join this
 
pilot project.
 
pilot project.
−
=== Recommended X.500 Implementation ===
+
 
 +
=== Recommended X.500 Implementation ===
 +
 
 
Interoperability testing has not been performed on most X.500
 
Interoperability testing has not been performed on most X.500
 
implementations.  Further, some X.500 functions are not mature
 
implementations.  Further, some X.500 functions are not mature
 
standards and are often added by implementors as noninteroperable
 
standards and are often added by implementors as noninteroperable
  
 +
extensions.
  
−
 
−
 
−
 
−
 
−
 
−
extensions.
 
 
To ensure interoperability for the entire ESnet community, the
 
To ensure interoperability for the entire ESnet community, the
 
University College London's publicly available X.500 implementation
 
University College London's publicly available X.500 implementation
Line 358: Line 256:
 
wide-spread use around the United States and Europe, including
 
wide-spread use around the United States and Europe, including
 
several ESnet backbone sites.
 
several ESnet backbone sites.
 +
 
Appendix C contains information on how to obtain QUIPU.
 
Appendix C contains information on how to obtain QUIPU.
 +
 
A later phase deployment of X.500 services within the ESnet community
 
A later phase deployment of X.500 services within the ESnet community
 
will recommend products (either commercial or public domain) which
 
will recommend products (either commercial or public domain) which
 
pass conformance and interoperability tests.
 
pass conformance and interoperability tests.
−
=== Naming Structure ===
+
 
 +
=== Naming Structure ===
 +
 
 
As participants in the PSI White Pages Pilot Project, ESnet backbone
 
As participants in the PSI White Pages Pilot Project, ESnet backbone
 
sites will align with the naming structure used by the Pilot.  This
 
sites will align with the naming structure used by the Pilot.  This
Line 373: Line 275:
 
are said to have national standing.  Therefore, a backbone site which
 
are said to have national standing.  Therefore, a backbone site which
 
is a national laboratory would be listed under country=US:
 
is a national laboratory would be listed under country=US:
 +
 
           @c=US@o=Lawrence Livermore National Laboratory
 
           @c=US@o=Lawrence Livermore National Laboratory
 +
 
As would a site with an ANSI-registered organization name:
 
As would a site with an ANSI-registered organization name:
 +
 
         @c=US@o=National Energy Research Supercomputer Center
 
         @c=US@o=National Energy Research Supercomputer Center
 +
 
A university would be listed below the state in which it is located:
 
A university would be listed below the state in which it is located:
 +
 
             @c=US@st=Florida@o=Florida State University
 
             @c=US@st=Florida@o=Florida State University
 +
 
And a commercial entity would be listed under the city or state in
 
And a commercial entity would be listed under the city or state in
 
which it is doing business, or "Doing Business As", depending upon
 
which it is doing business, or "Doing Business As", depending upon
 
where its DBA is registered:
 
where its DBA is registered:
 +
 
                 @c=US@st=California@o=General Atomics
 
                 @c=US@st=California@o=General Atomics
 
                                 (or)
 
                                 (or)
 
           @c=US@st=California@l=San Diego@o=General Atomics
 
           @c=US@st=California@l=San Diego@o=General Atomics
 +
 
A list of the current ESnet backbone sites, and their locations, is
 
A list of the current ESnet backbone sites, and their locations, is
  
 +
provided in Appendix E.
  
−
 
−
 
−
 
−
 
−
 
−
provided in Appendix E.
 
 
Directly connected ESnet backbone sites will be responsible for
 
Directly connected ESnet backbone sites will be responsible for
 
administering objects which reside below their respective portions of
 
administering objects which reside below their respective portions of
Line 402: Line 307:
 
for MIT could create an Organizational Unit named "Computer Science".
 
for MIT could create an Organizational Unit named "Computer Science".
 
This would appear in the DIT as:
 
This would appear in the DIT as:
 +
 
           @c=US@st=Massachusetts@o=MIT@ou=Computer Science
 
           @c=US@st=Massachusetts@o=MIT@ou=Computer Science
 +
 
Similarly, all other names created under the
 
Similarly, all other names created under the
 
"@c=US@st=Massachusetts@o=MIT" portion of the DIT would be
 
"@c=US@st=Massachusetts@o=MIT" portion of the DIT would be
Line 412: Line 319:
 
act in this capacity, they may designate another individual, at their
 
act in this capacity, they may designate another individual, at their
 
site, as the Name Registration Official.
 
site, as the Name Registration Official.
−
==== Implications of the Adoption of RFC-1255 by PSI ====
+
 
 +
==== Implications of the Adoption of RFC-1255 by PSI ====
 +
 
 
The North American Directory Forum (NADF) is comprised of commercial
 
The North American Directory Forum (NADF) is comprised of commercial
 
vendors positioning themselves to offer commercial X.500 Directory
 
vendors positioning themselves to offer commercial X.500 Directory
Line 422: Line 331:
 
pages 12-13 of RFC-1255, national-standing is defined in the
 
pages 12-13 of RFC-1255, national-standing is defined in the
 
following way:
 
following way:
 +
 
   "An organization is said to have national-standing if it is
 
   "An organization is said to have national-standing if it is
 
   chartered (created and named) by the U.S. Congress.  An example
 
   chartered (created and named) by the U.S. Congress.  An example
Line 430: Line 340:
 
   will be used as the public directory service basis for
 
   will be used as the public directory service basis for
 
   conferring national-standing on private organizations."
 
   conferring national-standing on private organizations."
 +
 
Thus, it appears that National Laboratories (e.g. LBL, LLNL) are
 
Thus, it appears that National Laboratories (e.g. LBL, LLNL) are
 
considered organizations with national-standing.  However, those
 
considered organizations with national-standing.  However, those
 
ESnet backbone sites which are not National Laboratories may wish to
 
ESnet backbone sites which are not National Laboratories may wish to
−
 
−
 
−
 
−
 
−
 
−
 
  
 
register with ANSI to have their organization list directly under
 
register with ANSI to have their organization list directly under
Line 445: Line 350:
 
providers defining a set of rules for information sharing and mutual
 
providers defining a set of rules for information sharing and mutual
 
interoperability in a commercial environment.
 
interoperability in a commercial environment.
 +
 
For further information on registering with ANSI, GSA or the U.S.
 
For further information on registering with ANSI, GSA or the U.S.
 
Patent and Trademark office, refer to Section 4 of this document.
 
Patent and Trademark office, refer to Section 4 of this document.
 
For more information on PSI, refer to Appendix A.
 
For more information on PSI, refer to Appendix A.
−
==== Universities and Commercial Entities ====
+
 
 +
==== Universities and Commercial Entities ====
 +
 
 
Several of the ESnet backbone sites are not National Laboratories
 
Several of the ESnet backbone sites are not National Laboratories
 
(e.g. CIT, FSU, GA, ISU, MIT, NYU, UCLA and UTA).  Typically, at
 
(e.g. CIT, FSU, GA, ISU, MIT, NYU, UCLA and UTA).  Typically, at
Line 459: Line 367:
 
participate in the recommended Phase I deployment of ESnet X.500
 
participate in the recommended Phase I deployment of ESnet X.500
 
services.  There are two possible solutions for this dilemma:
 
services.  There are two possible solutions for this dilemma:
 +
 
1.  If the site is not currently operating an X.500 DSA, the ESnet
 
1.  If the site is not currently operating an X.500 DSA, the ESnet
 
     Site Coordinator may be able to establish and administer a
 
     Site Coordinator may be able to establish and administer a
Line 468: Line 377:
 
     within the X.500 DIT, the ESnet Site Coordinator would have to
 
     within the X.500 DIT, the ESnet Site Coordinator would have to
 
     make arrangements to put option 2 into effect.
 
     make arrangements to put option 2 into effect.
 +
 
2.  If the site is currently operating an X.500 DSA, the ESnet
 
2.  If the site is currently operating an X.500 DSA, the ESnet
 
     Site Coordinator may be able to work out an agreement with the
 
     Site Coordinator may be able to work out an agreement with the
Line 478: Line 388:
 
     organizational unit "@c=US@st=Massachusetts@o=Massachusetts
 
     organizational unit "@c=US@st=Massachusetts@o=Massachusetts
 
     Institute of Technology@ ou=Physics".
 
     Institute of Technology@ ou=Physics".
−
==== Naming Structure Below the o=<site> Level ====
+
 
 +
==== Naming Structure Below the o=<site> Level ====
 +
 
 
The structure of the subtree below the organization's node in the DIT
 
The structure of the subtree below the organization's node in the DIT
 
is a matter for the local organization to decide.  A site's DSA
 
is a matter for the local organization to decide.  A site's DSA
−
 
−
 
−
 
−
 
−
 
−
 
  
 
manager will probably want to enlist input from others within the
 
manager will probably want to enlist input from others within the
 
organization before deciding how to structure the local DIT.
 
organization before deciding how to structure the local DIT.
 +
 
Some organizations currently participating in the Pilot have
 
Some organizations currently participating in the Pilot have
 
established a simple structure, choosing to limit the number of
 
established a simple structure, choosing to limit the number of
Line 499: Line 406:
 
more natural and can enhance the information obtained from browsing
 
more natural and can enhance the information obtained from browsing
 
the Directory.
 
the Directory.
 +
 
Below are experiences from current DSA managers, describing the way
 
Below are experiences from current DSA managers, describing the way
 
they structured their local DIT and the reasons for doing so.  A site
 
they structured their local DIT and the reasons for doing so.  A site
Line 504: Line 412:
 
their local DIT.  Ultimately this decision will depend upon the needs
 
their local DIT.  Ultimately this decision will depend upon the needs
 
of the local organization and expectations of Directory usage.
 
of the local organization and expectations of Directory usage.
 +
 
Valdis Kletnieks of the Virginia Polytechnic Institute:
 
Valdis Kletnieks of the Virginia Polytechnic Institute:
 +
 
   "For Virginia Tech, it turned out to be a reasonably
 
   "For Virginia Tech, it turned out to be a reasonably
 
   straightforward process.  Basically, the University is
 
   straightforward process.  Basically, the University is
 
   organized on a College/Department basis.  We decided to model
 
   organized on a College/Department basis.  We decided to model
 
   that "real" structure in the DIT for two major reasons:
 
   that "real" structure in the DIT for two major reasons:
 +
 
   "(a) It duplicates the way we do business, so interfacing the
 
   "(a) It duplicates the way we do business, so interfacing the
 
   X.500 directory with the "real world" is easier.
 
   X.500 directory with the "real world" is easier.
 +
 
   "(b) With 600+ departmental units and 11,000+ people (to be
 
   "(b) With 600+ departmental units and 11,000+ people (to be
 
   30,000+ once we add students), a "zero" (everybody at top) or
 
   30,000+ once we add students), a "zero" (everybody at top) or
Line 520: Line 432:
 
   having 30 departments, and the "average" department being from
 
   having 30 departments, and the "average" department being from
 
   10 to 40 people, it works out pretty well."
 
   10 to 40 people, it works out pretty well."
 +
 
Jeff Tannehill of Duke University:
 
Jeff Tannehill of Duke University:
 +
 
   "Our DIT is flat.  We get the entire database of people at Duke
 
   "Our DIT is flat.  We get the entire database of people at Duke
 
   from Tel-Com and just put everyone directly under "O=Duke
 
   from Tel-Com and just put everyone directly under "O=Duke
 
   University".
 
   University".
 +
 
   "Actually, there is an exception, when the DSA was first set up
 
   "Actually, there is an exception, when the DSA was first set up
 
   and we had not received a database yet, I configured the DIT to
 
   and we had not received a database yet, I configured the DIT to
 
   include "OU=Computer Science", under which myself and one other
 
   include "OU=Computer Science", under which myself and one other
−
 
−
 
−
 
−
 
−
 
−
 
  
 
   System Administrator have entries.  Upon getting the database
 
   System Administrator have entries.  Upon getting the database
 
   for everyone else I decided not to attempt to separate the
 
   for everyone else I decided not to attempt to separate the
 
   people in the database into multiple ou's."
 
   people in the database into multiple ou's."
 +
 
Joe Carlson of Lawrence Livermore National Laboratory:
 
Joe Carlson of Lawrence Livermore National Laboratory:
 +
 
   "We tried both flat (actually all under the same OU) and
 
   "We tried both flat (actually all under the same OU) and
 
   splitting based on internal department name and ended up with
 
   splitting based on internal department name and ended up with
 
   flat.  Our primary reason was load and search times, which were
 
   flat.  Our primary reason was load and search times, which were
 
   2-3 times faster for flat organization."
 
   2-3 times faster for flat organization."
 +
 
Paul Mauvais of Portland State University:
 
Paul Mauvais of Portland State University:
 +
 
   "We originally set up our DIT by simply loading our campus
 
   "We originally set up our DIT by simply loading our campus
 
   phone book into one level down from the top (e.g. OU=Faculty
 
   phone book into one level down from the top (e.g. OU=Faculty
 
   and Staff, OU=Students, OU=Computing Services).
 
   and Staff, OU=Students, OU=Computing Services).
 +
 
   "I'd love to have an easy way to convert our flat faculty and
 
   "I'd love to have an easy way to convert our flat faculty and
 
   staff area into departments and colleges, but the time to
 
   staff area into departments and colleges, but the time to
 
   convert the data into the separate OU's is probably more than I
 
   convert the data into the separate OU's is probably more than I
 
   have right now."
 
   have right now."
 +
 
Mohamed Ellozy of Dana-Farber Cancer Institute:
 
Mohamed Ellozy of Dana-Farber Cancer Institute:
 +
 
   "Here we have a phone database that includes department, so we
 
   "Here we have a phone database that includes department, so we
 
   got the ou's with no effort.  We thus never went the flat space
 
   got the ou's with no effort.  We thus never went the flat space
 
   way."
 
   way."
 +
 
Dan Moline of TRW:
 
Dan Moline of TRW:
 +
 
   "Well - we're still in the process of defining our DIT.  TRW
 
   "Well - we're still in the process of defining our DIT.  TRW
 
   comes under the international companies DBA.  Our part under
 
   comes under the international companies DBA.  Our part under
Line 562: Line 480:
 
   from our manpower DB for our S&D personnel.  We're trying to
 
   from our manpower DB for our S&D personnel.  We're trying to
 
   get corporate's DB for possible input.
 
   get corporate's DB for possible input.
 +
 
   "However, arranging your DIT by organizations (at least for
 
   "However, arranging your DIT by organizations (at least for
 
   corps) presents a problem; things are always being reorganized!
 
   corps) presents a problem; things are always being reorganized!
Line 567: Line 486:
 
   domain name for DNS tied to organizations that have not existed
 
   domain name for DNS tied to organizations that have not existed
 
   for years!
 
   for years!
 +
 
   "So we are currently redesigning our DIT to try to fit NADF 175
 
   "So we are currently redesigning our DIT to try to fit NADF 175
 
   (something more geographically).  Our reasoning was that
 
   (something more geographically).  Our reasoning was that
 
   organizations may change but buildings and localities do not."
 
   organizations may change but buildings and localities do not."
  
 +
Ruth Lang of SRI:
  
−
 
−
 
−
 
−
 
−
 
−
 
−
Ruth Lang of SRI:
 
 
   "There has been no SRI-wide policy or decision to participate
 
   "There has been no SRI-wide policy or decision to participate
 
   in the PSI White Pages Pilot.  @c=US@O=SRI International
 
   in the PSI White Pages Pilot.  @c=US@O=SRI International
Line 587: Line 501:
 
   If I were to structure the DIT for all of SRI, I'm sure that my
 
   If I were to structure the DIT for all of SRI, I'm sure that my
 
   thinking would yield a much different structure."
 
   thinking would yield a much different structure."
 +
 
Russ Wright of Lawrence Berkeley Laboratory:
 
Russ Wright of Lawrence Berkeley Laboratory:
 +
 
   "Since we don't have much organizational information in current
 
   "Since we don't have much organizational information in current
 
   staff database, I have to stick to a fairly flat structure.  I
 
   staff database, I have to stick to a fairly flat structure.  I
Line 593: Line 509:
 
   guests (there is a flag in our database that is set for
 
   guests (there is a flag in our database that is set for
 
   guests).
 
   guests).
 +
 
   "I may add an additional level of OUs to our current structure.
 
   "I may add an additional level of OUs to our current structure.
 
   The top level would contain different 'types' of information.
 
   The top level would contain different 'types' of information.
Line 598: Line 515:
 
   publications).  Staff and Guests would reside under the
 
   publications).  Staff and Guests would reside under the
 
   Personnel OU."
 
   Personnel OU."
 +
 
Peter Yee of NASA Ames:
 
Peter Yee of NASA Ames:
 +
 
   "I broke up my DIT at the NASA Center level.  NASA is made of
 
   "I broke up my DIT at the NASA Center level.  NASA is made of
 
   nearly 20 Centers and Facilities.  The decision to break up at
 
   nearly 20 Centers and Facilities.  The decision to break up at
 
   this level was driven by several factors:
 
   this level was driven by several factors:
 +
 
   "1.  Control of the local portion of the DIT should reside with
 
   "1.  Control of the local portion of the DIT should reside with
 
   the Center in question, particularly since the Center probably
 
   the Center in question, particularly since the Center probably
 
   supplies the data in question and controls the matching DSA.
 
   supplies the data in question and controls the matching DSA.
 +
 
   "2.  Each Center ranges in size from 1,000 to 16,000 persons.
 
   "2.  Each Center ranges in size from 1,000 to 16,000 persons.
 
   This seems to be the range that works well on moderate sized
 
   This seems to be the range that works well on moderate sized
 
   UNIX servers.  Smaller would be a waste, larger would require
 
   UNIX servers.  Smaller would be a waste, larger would require
 
   too much memory.
 
   too much memory.
 +
 
   "3.  Representatives from several Centers have contacted me
 
   "3.  Representatives from several Centers have contacted me
 
   asking if they could run their own DSAs so that they can
 
   asking if they could run their own DSAs so that they can
 
   experiment with X.500.  Thus the relevant DSA needs to be under
 
   experiment with X.500.  Thus the relevant DSA needs to be under
 
   their control."
 
   their control."
−
===  Information Stored in X.500 ===
 
−
The Phase I deployment of X.500 should be limited to "white pages"-
 
−
 
−
 
−
 
−
 
  
 +
=== Information Stored in X.500 ===
  
 +
The Phase I deployment of X.500 should be limited to "white pages"-
  
 
type information about people.  Other types of objects can be added
 
type information about people.  Other types of objects can be added
 
in later Phases, or added dynamically as the need arises.
 
in later Phases, or added dynamically as the need arises.
 +
 
To make X.500 truly useful to the ESnet community as a White Pages
 
To make X.500 truly useful to the ESnet community as a White Pages
 
service, it is recommended that the following minimum information
 
service, it is recommended that the following minimum information
 
should be stored in the X.500 database:
 
should be stored in the X.500 database:
 +
 
Information  ASN.1 Attribute Type      Example
 
Information  ASN.1 Attribute Type      Example
 
-----------  --------------------      -------
 
-----------  --------------------      -------
Line 636: Line 556:
 
               telephoneNumber          +1 510 422 8266
 
               telephoneNumber          +1 510 422 8266
 
               facsimileTelephoneNumber  +1 510 422 0435
 
               facsimileTelephoneNumber  +1 510 422 0435
 +
 
E-Mail Info  rfc822Mailbox            [email protected]
 
E-Mail Info  rfc822Mailbox            [email protected]
 
               mhsORAddresses            /PN=Allen Sturtevant/O=NERSC/
 
               mhsORAddresses            /PN=Allen Sturtevant/O=NERSC/
 
                                           /PRMD=ESnet/ADMD= /C=US/
 
                                           /PRMD=ESnet/ADMD= /C=US/
 
               otherMailbox              DECnet:  ESNIC::APS
 
               otherMailbox              DECnet:  ESNIC::APS
 +
 
The above list of attributes comprises a minimum set which is
 
The above list of attributes comprises a minimum set which is
 
recommended for a person's entry.  However, you may chose to omit
 
recommended for a person's entry.  However, you may chose to omit
Line 648: Line 570:
 
Number" and postal address to allow some means of contacting the
 
Number" and postal address to allow some means of contacting the
 
person.
 
person.
−
==== Information Security ====
+
 
 +
==== Information Security ====
 +
 
 
It is understood that placing this type of information in X.500 is
 
It is understood that placing this type of information in X.500 is
 
equivalent to putting the "Company Phone Book" on-line in the
 
equivalent to putting the "Company Phone Book" on-line in the
Line 658: Line 582:
 
currently exists minimal access control in several X.500
 
currently exists minimal access control in several X.500
 
implementations.
 
implementations.
−
=== Accessing the X.500 Directory Service ===
+
 
 +
=== Accessing the X.500 Directory Service ===
 +
 
 
The PSI White Pages Pilot Project software provides numerous
 
The PSI White Pages Pilot Project software provides numerous
 
interfaces to the information in the X.500 Directory.  Non-
 
interfaces to the information in the X.500 Directory.  Non-
 
interactive access mechanisms (e.g. WHOIS, FINGER and Electronic
 
interactive access mechanisms (e.g. WHOIS, FINGER and Electronic
−
 
−
 
−
 
−
 
−
 
−
 
  
 
Mail) make use of capabilities or services which already reside on
 
Mail) make use of capabilities or services which already reside on
Line 675: Line 595:
 
interactive, they only provide a way to search for and read
 
interactive, they only provide a way to search for and read
 
information in the Directory but no way to modify information.
 
information in the Directory but no way to modify information.
−
==== Directory Service via WHOIS ====
+
 
 +
==== Directory Service via WHOIS ====
 +
 
 
The Pilot Project software allows you to configure the X.500
 
The Pilot Project software allows you to configure the X.500
 
Directory service to be made available via a network port offering an
 
Directory service to be made available via a network port offering an
Line 684: Line 606:
 
information about colleagues at their site or at other ESnet sites.
 
information about colleagues at their site or at other ESnet sites.
 
For example, the command:
 
For example, the command:
 +
 
   whois -h wp.lbl.gov wright
 
   whois -h wp.lbl.gov wright
 +
 
will return information about Russ Wright at Lawrence Berkeley Lab.
 
will return information about Russ Wright at Lawrence Berkeley Lab.
 
It is recommended that all sites which bring up such a service,
 
It is recommended that all sites which bring up such a service,
 
should provide an alias name for the host running their DSA of the
 
should provide an alias name for the host running their DSA of the
 
form <wp.site.domain> for consistency within the ESnet community.
 
form <wp.site.domain> for consistency within the ESnet community.
−
==== Directory Service via Electronic Mail ====
+
 
 +
==== Directory Service via Electronic Mail ====
 +
 
 
The Pilot Project software also allows the X.500 Directory service to
 
The Pilot Project software also allows the X.500 Directory service to
 
be made available via electronic mail.  A user who sends an
 
be made available via electronic mail.  A user who sends an
Line 695: Line 621:
 
WHOIS-like command on the subject line, would then receive a return
 
WHOIS-like command on the subject line, would then receive a return
 
mail message containing the results of their query.
 
mail message containing the results of their query.
−
==== Directory Service via FINGER ====
+
 
 +
==== Directory Service via FINGER ====
 +
 
 
The X.500 Directory service could also be made available via the
 
The X.500 Directory service could also be made available via the
 
FINGER service.  Although this access method does not come with the
 
FINGER service.  Although this access method does not come with the
Line 703: Line 631:
 
individual implementations within the ESnet community should conform
 
individual implementations within the ESnet community should conform
 
to this interface.
 
to this interface.
−
==== Directory Service via Specialized Applications ====
+
 
 +
==== Directory Service via Specialized Applications ====
 +
 
 
Many X.500 Directory User Agents (DUAs) are widely available.  Some
 
Many X.500 Directory User Agents (DUAs) are widely available.  Some
 
of these come with the PSI Pilot Project software.  Other DUAs, which
 
of these come with the PSI Pilot Project software.  Other DUAs, which
 
have been developed by third parties to fit into the pilot software,
 
have been developed by third parties to fit into the pilot software,
−
 
−
 
−
 
−
 
−
 
−
 
  
 
are publicly available.  These user agents support interactive access
 
are publicly available.  These user agents support interactive access
Line 720: Line 644:
 
host system.  Only a few of these DUAs and their capabilities are
 
host system.  Only a few of these DUAs and their capabilities are
 
described below.
 
described below.
 +
 
o  DISH - A User Agent which provides a textual interface to the
 
o  DISH - A User Agent which provides a textual interface to the
 
   X.500 Directory.  It gives full access to all elements of the
 
   X.500 Directory.  It gives full access to all elements of the
 
   Directory Access Protocol (DAP) and as such may be complex for
 
   Directory Access Protocol (DAP) and as such may be complex for
 
   novice users.  DISH is most useful to the DSA administrator.
 
   novice users.  DISH is most useful to the DSA administrator.
 +
 
o  FRED - A User Agent which has been optimized for "white pages"
 
o  FRED - A User Agent which has been optimized for "white pages"
 
   types of queries.  The FRED program is meant to be similar to
 
   types of queries.  The FRED program is meant to be similar to
 
   the WHOIS network service.  FRED supports reading, searching,
 
   the WHOIS network service.  FRED supports reading, searching,
 
   and modifying information in the X.500 Directory.
 
   and modifying information in the X.500 Directory.
 +
 
o  POD - An X-windows based User Agent intended for novice users.
 
o  POD - An X-windows based User Agent intended for novice users.
 
   POD relies heavily on the concept of the user "navigating"
 
   POD relies heavily on the concept of the user "navigating"
Line 733: Line 660:
 
   no facilities to add entries or to modify the RDNs of entries,
 
   no facilities to add entries or to modify the RDNs of entries,
 
   though most other entry modifications are allowed.
 
   though most other entry modifications are allowed.
−
==== Directory Service from PCs and MACs ====
+
 
 +
==== Directory Service from PCs and MACs ====
 +
 
 
Smaller workstations and personal computers lack the computing power
 
Smaller workstations and personal computers lack the computing power
 
or necessary software to implement a full OSI protocol stack.  As a
 
or necessary software to implement a full OSI protocol stack.  As a
Line 747: Line 676:
 
Agents on many end-systems without having to install the Pilot
 
Agents on many end-systems without having to install the Pilot
 
software on all those end-systems.
 
software on all those end-systems.
 +
 
For further information about available Directory User Agents, see
 
For further information about available Directory User Agents, see
 
RFC-1292, "Catalog of Available X.500 Implementations".
 
RFC-1292, "Catalog of Available X.500 Implementations".
−
=== Services Provided by ESnet ===
+
 
 +
=== Services Provided by ESnet ===
 +
 
 
Currently, there are several ESnet backbone sites which are operating
 
Currently, there are several ESnet backbone sites which are operating
 
their own DSAs within the PSI White Pages Pilot Project.  It is
 
their own DSAs within the PSI White Pages Pilot Project.  It is
Line 755: Line 687:
 
eventually install and operate their own X.500 DSAs.  In the interim,
 
eventually install and operate their own X.500 DSAs.  In the interim,
  
−
 
+
ESnet will provide complete support for ESnet backbone sites which
−
 
+
presently do not have the time, expertise or equipment to establish
−
 
 
−
 
 
−
 
 
−
 
 
−
ESnet will provide complete support for ESnet backbone sites which
 
−
presently do not have the time, expertise or equipment to establish
 
 
X.500 services.  The mechanism for doing this is described in Section
 
X.500 services.  The mechanism for doing this is described in Section
 
2.7.5 below.  Additionally, ESnet will provide a variety of services
 
2.7.5 below.  Additionally, ESnet will provide a variety of services
 
in support of the entire X.500 community.  These are also described
 
in support of the entire X.500 community.  These are also described
 
in the following sections.
 
in the following sections.
−
==== X.500 Operations Mailing List ====
+
 
 +
==== X.500 Operations Mailing List ====
 +
 
 
ESnet maintains a mailing list for the discussion of relevant X.500
 
ESnet maintains a mailing list for the discussion of relevant X.500
 
topics. This mailing list provides a means for sharing information,
 
topics. This mailing list provides a means for sharing information,
Line 776: Line 704:
 
X.500 DSA, the DSA manager should notify the ESnet DSA manager so as
 
X.500 DSA, the DSA manager should notify the ESnet DSA manager so as
 
to ensure they are promptly added to the mailing list.
 
to ensure they are promptly added to the mailing list.
 +
 
   General discussion:  [email protected]
 
   General discussion:  [email protected]
 
   To subscribe:        [email protected]
 
   To subscribe:        [email protected]
−
==== Accessing the X.500 Directory ====
+
 
 +
==== Accessing the X.500 Directory ====
 +
 
 
ESnet has made the X.500 service openly available to the entire ESnet
 
ESnet has made the X.500 service openly available to the entire ESnet
 
community via each of the access methods described in Section 2.6
 
community via each of the access methods described in Section 2.6
Line 786: Line 717:
 
available, we hope to acquaint more users with the features and
 
available, we hope to acquaint more users with the features and
 
capabilities of X.500.
 
capabilities of X.500.
 +
 
To try out some of the X.500 User Agents, simply TELNET to WP.ES.NET
 
To try out some of the X.500 User Agents, simply TELNET to WP.ES.NET
 
and login as user "fred"; no password is required.  You have the
 
and login as user "fred"; no password is required.  You have the
Line 793: Line 725:
 
persons in various organizations, and even modify your own entry if
 
persons in various organizations, and even modify your own entry if
 
you have one.
 
you have one.
 +
 
Host WP.ES.NET also provides access to the X.500 Directory via
 
Host WP.ES.NET also provides access to the X.500 Directory via
 
emulations of the FINGER and WHOIS utilities.  These interfaces
 
emulations of the FINGER and WHOIS utilities.  These interfaces
Line 800: Line 733:
 
various ESnet sites, utilizing the UFN syntax (similar FINGER command
 
various ESnet sites, utilizing the UFN syntax (similar FINGER command
 
lines could also be constructed):
 
lines could also be constructed):
−
 
−
 
−
 
−
 
−
 
−
 
−
 
−
 
  
 
   whois -h wp.es.net leighton,nersc
 
   whois -h wp.es.net leighton,nersc
Line 813: Line 738:
 
   whois -h wp.es.net logg,slac
 
   whois -h wp.es.net logg,slac
 
   whois -h wp.es.net "russ wright",lbl
 
   whois -h wp.es.net "russ wright",lbl
 +
 
For further information about User Friendly Naming, see Steve
 
For further information about User Friendly Naming, see Steve
 
Hardcastle-Kille's working document titled, "Using the OSI Directory
 
Hardcastle-Kille's working document titled, "Using the OSI Directory
 
to Achieve User Friendly Naming".
 
to Achieve User Friendly Naming".
−
==== Backbone Site Aliases ====
+
 
 +
==== Backbone Site Aliases ====
 +
 
 
As ESnet backbone sites join the X.500 pilot, their organizations'
 
As ESnet backbone sites join the X.500 pilot, their organizations'
 
entries will be placed in various parts of the DIT.  For example,
 
entries will be placed in various parts of the DIT.  For example,
Line 822: Line 750:
 
of the DIT, while universities and commercial entities will most
 
of the DIT, while universities and commercial entities will most
 
likely be placed under localities, such as states or cities.
 
likely be placed under localities, such as states or cities.
 +
 
In order to facilitate searching for the ESnet community as a whole,
 
In order to facilitate searching for the ESnet community as a whole,
 
ESnet backbone sites will also be listed as organizational units
 
ESnet backbone sites will also be listed as organizational units
Line 829: Line 758:
 
different places in the DIT and one could search for them in either
 
different places in the DIT and one could search for them in either
 
location.
 
location.
−
==== Multiprotocol Stack Support ====
+
 
 +
==== Multiprotocol Stack Support ====
 +
 
 
OSI applications currently run over many different transport/network
 
OSI applications currently run over many different transport/network
 
protocols, a factor which hinders communication between OSI end
 
protocols, a factor which hinders communication between OSI end
Line 835: Line 766:
 
configured at compile time to support any combination of the
 
configured at compile time to support any combination of the
 
following stacks:
 
following stacks:
 +
 
   RFC-1006 over TCP/IP
 
   RFC-1006 over TCP/IP
 
   TP0      over X.25
 
   TP0      over X.25
Line 840: Line 772:
 
   TP0      over the TP0-bridge
 
   TP0      over the TP0-bridge
 
   TP4      over CLNP
 
   TP4      over CLNP
 +
 
Within the ESnet community, the stacks of interest are RFC-1006 over
 
Within the ESnet community, the stacks of interest are RFC-1006 over
 
TCP/IP, TP4 over CLNP, and TP0 over X.25.  If a backbone site's DSA
 
TCP/IP, TP4 over CLNP, and TP0 over X.25.  If a backbone site's DSA
Line 850: Line 783:
 
DSA manager to arrange for this relaying to occur.  Backbone sites
 
DSA manager to arrange for this relaying to occur.  Backbone sites
  
 +
will be encouraged to eventually provide as many of the three stacks
 +
of interest as possible.
  
 +
==== Managing a Site's X.500 Information ====
  
−
 
−
 
−
 
−
 
−
will be encouraged to eventually provide as many of the three stacks
 
−
of interest as possible.
 
−
====  Managing a Site's X.500 Information ====
 
 
For sites which do not initially wish to operate their own DSA,
 
For sites which do not initially wish to operate their own DSA,
 
ESnet's DSA will master their site's portion of the DIT, enabling the
 
ESnet's DSA will master their site's portion of the DIT, enabling the
Line 866: Line 795:
 
Directory.  This information can usually be obtained from your Site's
 
Directory.  This information can usually be obtained from your Site's
 
Personnel Database.
 
Personnel Database.
 +
 
ESnet will only maintain a limited amount of information on behalf of
 
ESnet will only maintain a limited amount of information on behalf of
 
each person to be represented in the Directory.  The attribute types
 
each person to be represented in the Directory.  The attribute types
Line 874: Line 804:
 
Therefore, if a site wishes to include additional attribute types,
 
Therefore, if a site wishes to include additional attribute types,
 
they should consider installing and operating their own DSA.
 
they should consider installing and operating their own DSA.
 +
 
The format of the information to be provided to the ESnet DSA manager
 
The format of the information to be provided to the ESnet DSA manager
 
is as follows:  the data should be contained in a flat, ASCII text
 
is as follows:  the data should be contained in a flat, ASCII text
Line 879: Line 810:
 
separating the fields of the record.  More detailed information and a
 
separating the fields of the record.  More detailed information and a
 
sample of a site-supplied data file can be found in Appendix D.
 
sample of a site-supplied data file can be found in Appendix D.
−
===== Open Availability of Site Information =====
+
 
 +
===== Open Availability of Site Information =====
 +
 
 
Although the PSI Pilot Project allows you to control who may access
 
Although the PSI Pilot Project allows you to control who may access
 
Directory objects and their attributes, any information you provide
 
Directory objects and their attributes, any information you provide
Line 890: Line 823:
 
provide this information to the ESnet DSA manager or you should
 
provide this information to the ESnet DSA manager or you should
 
consider installing and administering your own DSA.
 
consider installing and administering your own DSA.
−
===== Access Methods for Local Users =====
+
 
 +
===== Access Methods for Local Users =====
 +
 
 
Backbone sites which choose the option of having the ESnet DSA master
 
Backbone sites which choose the option of having the ESnet DSA master
 
their organization's X.500 information should make the availability
 
their organization's X.500 information should make the availability
Line 896: Line 831:
 
described in Section 2.7.2 are available for use, but none of these
 
described in Section 2.7.2 are available for use, but none of these
 
methods will assume the query is relative to the local site.
 
methods will assume the query is relative to the local site.
−
 
−
 
−
 
−
 
−
 
−
 
  
 
To facilitate querying relative to the local environment, the site
 
To facilitate querying relative to the local environment, the site
Line 910: Line 839:
 
site XYZ could type the following, omitting their local domain name
 
site XYZ could type the following, omitting their local domain name
 
as this is implied:
 
as this is implied:
 +
 
   finger jones@wp
 
   finger jones@wp
 +
 
This will retrieve information about user Jones at site XYZ (wp is
 
This will retrieve information about user Jones at site XYZ (wp is
 
the name or alias of a host at site XYZ, i.e. wp.XYZ.GOV).  The site
 
the name or alias of a host at site XYZ, i.e. wp.XYZ.GOV).  The site
 
coordinator will need to contact the ESnet DSA manager to arrange the
 
coordinator will need to contact the ESnet DSA manager to arrange the
 
set up for this service.
 
set up for this service.
−
===== Limitations of Using ESnet Services =====
+
 
 +
===== Limitations of Using ESnet Services =====
 +
 
 
Since the ESnet DSA will potentially be mastering information on
 
Since the ESnet DSA will potentially be mastering information on
 
behalf of numerous backbone sites, limits will need to be placed on
 
behalf of numerous backbone sites, limits will need to be placed on
Line 921: Line 854:
 
enforced to ensure DSA responsiveness, as well as to reduce
 
enforced to ensure DSA responsiveness, as well as to reduce
 
administrative maintenance.  The limits are:
 
administrative maintenance.  The limits are:
 +
 
               Item                      Maximum Limit
 
               Item                      Maximum Limit
 
               ----                      -------------
 
               ----                      -------------
Line 930: Line 864:
 
               Aliases                              n/a
 
               Aliases                              n/a
 
               Object/Attribute Access Control      n/a
 
               Object/Attribute Access Control      n/a
 +
 
One week before each monthly update cycle, a message will be sent on
 
One week before each monthly update cycle, a message will be sent on
 
the [email protected] mailer to remind the sites that an update cycle
 
the [email protected] mailer to remind the sites that an update cycle
Line 938: Line 873:
 
DSA manager before the next update cycle.  More detailed information
 
DSA manager before the next update cycle.  More detailed information
 
and a sample of a site-supplied data file can be found in Appendix D.
 
and a sample of a site-supplied data file can be found in Appendix D.
−
=== ESnet Running a Level-0 DSA for c=US ===
+
 
 +
=== ESnet Running a Level-0 DSA for c=US ===
 +
 
 
For ESnet to provide high quality X.500 services to the ESnet
 
For ESnet to provide high quality X.500 services to the ESnet
 
community, the ESnet DSAs must operate as Level-0 (first level) DSAs.
 
community, the ESnet DSAs must operate as Level-0 (first level) DSAs.
 
It is currently planned that these DSAs will act as slave, Level-0
 
It is currently planned that these DSAs will act as slave, Level-0
 
DSAs to PSI's master, Level-0 DSAs.  Once the ESnet DSAs are in
 
DSAs to PSI's master, Level-0 DSAs.  Once the ESnet DSAs are in
−
 
−
 
−
 
−
 
−
 
−
 
  
 
production service, it is recommended that directly connected ESnet
 
production service, it is recommended that directly connected ESnet
Line 954: Line 885:
 
of the ESnet DSAs as their parent DSA.  This provides several
 
of the ESnet DSAs as their parent DSA.  This provides several
 
advantages to the ESnet community:
 
advantages to the ESnet community:
 +
 
1.  The ESnet DSAs will be monitored by the NERSC's 24-hour
 
1.  The ESnet DSAs will be monitored by the NERSC's 24-hour
 
     Operations Staff.  Additionally, ESnet plans to deploy two
 
     Operations Staff.  Additionally, ESnet plans to deploy two
 
     (2) DSAs in geographically disperse locations to ensure
 
     (2) DSAs in geographically disperse locations to ensure
 
     reliability and availability.
 
     reliability and availability.
 +
 
2.  All queries to Level-0 DSAs remain within the ESnet high-speed
 
2.  All queries to Level-0 DSAs remain within the ESnet high-speed
 
     backbone.
 
     backbone.
 +
 
3.  If network connectivity is lost to all external Level-0 DSAs,
 
3.  If network connectivity is lost to all external Level-0 DSAs,
 
     X.500 Level-0 connectivity will still exist within the ESnet
 
     X.500 Level-0 connectivity will still exist within the ESnet
 
     backbone.
 
     backbone.
−
=== X.500 Registration Requirements ===
+
 
 +
=== X.500 Registration Requirements ===
 +
 
 
X.500 organization names must be nationally unique if they appear
 
X.500 organization names must be nationally unique if they appear
 
directly below the c=US level in the DIT structure.  Nationally
 
directly below the c=US level in the DIT structure.  Nationally
 
unique names must be registered through an appropriate registration
 
unique names must be registered through an appropriate registration
 
authority, i.e., one which grants nationally unique names.
 
authority, i.e., one which grants nationally unique names.
 +
 
X.500 organizational unit names need to be unique relative to the
 
X.500 organizational unit names need to be unique relative to the
 
node directly superior to them in the DIT.  Registration of these
 
node directly superior to them in the DIT.  Registration of these
 
names should be conducted through the "owner" of the superior node.
 
names should be conducted through the "owner" of the superior node.
 +
 
The registration of X.500 names below the organization level are
 
The registration of X.500 names below the organization level are
 
usually a local matter.  However, all siblings under a given node in
 
usually a local matter.  However, all siblings under a given node in
 
the DIT must have unique RDNs.
 
the DIT must have unique RDNs.
 +
 
See Section 4 for a more complete description of OSI registration
 
See Section 4 for a more complete description of OSI registration
 
issues and procedures.
 
issues and procedures.
 +
 
2.10.  Future X.500 Issues to be Considered
 
2.10.  Future X.500 Issues to be Considered
 +
 
2.10.1.  ADDMDS Interoperating with PRDMDS
 
2.10.1.  ADDMDS Interoperating with PRDMDS
 +
 
This is a problem which currently does not have an answer.  The issue
 
This is a problem which currently does not have an answer.  The issue
 
of Administrative Directory Management Domains (ADDMDs) interacting
 
of Administrative Directory Management Domains (ADDMDs) interacting
Line 983: Line 925:
 
to be investigated by several groups interested in solving this
 
to be investigated by several groups interested in solving this
 
problem.
 
problem.
 +
 
2.10.2.  X.400 Interaction with X.500
 
2.10.2.  X.400 Interaction with X.500
 +
 
The current level of understanding is that X.400 can benefit from the
 
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
−
 
 
−
 
 
−
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
 
both of these features in a fully integrated fashion across multiple
 
vendors.  As the standards and technology evolve, consideration will
 
vendors.  As the standards and technology evolve, consideration will
 
have to be given in applying these new functions to the production
 
have to be given in applying these new functions to the production
 
ESnet X.500/X.400 services environment.
 
ESnet X.500/X.400 services environment.
 +
 
2.10.3.  Use of X.500 for NIC Information
 
2.10.3.  Use of X.500 for NIC Information
 +
 
Work is currently being performed in the IETF to place NIC
 
Work is currently being performed in the IETF to place NIC
 
information on-line in an Internet-based X.500 service.
 
information on-line in an Internet-based X.500 service.
 +
 
2.10.4.  Use of X.500 for Non-White Pages Information
 
2.10.4.  Use of X.500 for Non-White Pages Information
 +
 
The PSI White Pages Pilot Project has caused increasing and popular
 
The PSI White Pages Pilot Project has caused increasing and popular
 
use of X.500 as a white pages services within the Internet community.
 
use of X.500 as a white pages services within the Internet community.
Line 1,010: Line 955:
 
just a few of the objects to be considered for future incorporation
 
just a few of the objects to be considered for future incorporation
 
in the global X.500 database.
 
in the global X.500 database.
 +
 
2.10.5.  Introduction of New X.500 Implementations
 
2.10.5.  Introduction of New X.500 Implementations
 +
 
Thought will have to be given to the use of commercial X.500 products
 
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)
 
in the future as QUIPU (the implementation recommended in this paper)
Line 1,017: Line 964:
 
into the ESnet X.500 service in a way which ensures interoperability
 
into the ESnet X.500 service in a way which ensures interoperability
 
and reliability.
 
and reliability.
 +
 
2.10.6.  Interaction of X.500 and DECdns
 
2.10.6.  Interaction of X.500 and DECdns
 +
 
There is every indication that DECdns and X.500 will interoperate in
 
There is every indication that DECdns and X.500 will interoperate in
 
some fashion in the future.  Since there is an evolving DECdns
 
some fashion in the future.  Since there is an evolving DECdns
Line 1,026: Line 975:
 
product with X.500.
 
product with X.500.
  
 +
== X.400 - OSI Message Handling Services ==
  
 +
=== Brief Tutorial ===
  
−
 
−
 
−
 
−
 
−
 
−
 
−
 
−
 
−
==  X.400 - OSI Message Handling Services ==
 
−
===  Brief Tutorial ===
 
 
In 1984 CCITT defined a set of protocols for the exchange of
 
In 1984 CCITT defined a set of protocols for the exchange of
 
electronic messages called Message Handling Systems (MHS) and is
 
electronic messages called Message Handling Systems (MHS) and is
Line 1,051: Line 992:
 
as used for electronic mail.  In the following sections, the term
 
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.
 
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
 
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
 
System (MTS) accessed via a User Agent (UA).  A UA is an application
Line 1,060: Line 1,002:
 
for delivery.  The MTS then delivers the message to one or more
 
for delivery.  The MTS then delivers the message to one or more
 
Recipient UAs.
 
Recipient UAs.
 +
 
                 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
 
                 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
 
     ______      |      _______          _______    |    ______
 
     ______      |      _______          _______    |    ______
Line 1,066: Line 1,009:
 
   |______|    |    |_______|        |_______|    |    |______|
 
   |______|    |    |_______|        |_______|    |    |______|
 
                 |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|
 
                 |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|
 +
 
The MTS provides the general store-and-forward message transfer
 
The MTS provides the general store-and-forward message transfer
 
service. It is made up of a number of distributed Message Transfer
 
service. It is made up of a number of distributed Message Transfer
Line 1,071: Line 1,015:
 
deliver them to the intended recipient UAs, which then makes the
 
deliver them to the intended recipient UAs, which then makes the
 
messages available to the recipient (user).
 
messages available to the recipient (user).
 +
 
The basic structure of an X.400 message is an envelope and content
 
The basic structure of an X.400 message is an envelope and content
 
(i.e.  message).  The envelope carries information to be used when
 
(i.e.  message).  The envelope carries information to be used when
Line 1,078: Line 1,023:
 
carried in X.400 envelopes.  The standard user message content type
 
carried in X.400 envelopes.  The standard user message content type
 
defined by X.400 is called the Interpersonal (IP) message.  An IP
 
defined by X.400 is called the Interpersonal (IP) message.  An IP
−
 
−
 
−
 
−
 
−
 
−
 
  
 
message consists of two parts, the heading and body.  The heading
 
message consists of two parts, the heading and body.  The heading
Line 1,090: Line 1,029:
 
For example one IP message could carry voice, text, Telex and
 
For example one IP message could carry voice, text, Telex and
 
facsimile body parts.
 
facsimile body parts.
 +
 
The Management domain (MD) concept within the X.400 recommendations
 
The Management domain (MD) concept within the X.400 recommendations
 
defines the ownership, operational and control boundary of an X.400
 
defines the ownership, operational and control boundary of an X.400
Line 1,100: Line 1,040:
 
exist entirely within one country.  Within that country a PRMD may
 
exist entirely within one country.  Within that country a PRMD may
 
have access to one or more ADMDs.
 
have access to one or more ADMDs.
 +
 
Each MD must ensure that every user (i.e UA) in the MD has at least
 
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.
 
one name.  This name is called the Originator/Recipient (O/R) Name.
 
O/R Names are constructed from a set of standard attributes:
 
O/R Names are constructed from a set of standard attributes:
 +
 
o  Country Name
 
o  Country Name
 +
 
o  Administration Management Domain
 
o  Administration Management Domain
 +
 
o  Private Management Domain
 
o  Private Management Domain
 +
 
o  Organization Name
 
o  Organization Name
 +
 
o  Organizational Unit Name
 
o  Organizational Unit Name
 +
 
o  Surname
 
o  Surname
 +
 
o  Given name
 
o  Given name
 +
 
o  Initials
 
o  Initials
 +
 
o  Generational Qualifier
 
o  Generational Qualifier
 +
 
An O/R name must locate one unambiguous O/R UA if the message is to
 
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
 
be routed correctly through the Message Transfer Service.  Currently
Line 1,119: Line 1,070:
 
or in any other MD that acquires the store and forward responsibility
 
or in any other MD that acquires the store and forward responsibility
 
for the message.
 
for the message.
 +
 
Messages are relayed by each MD on the basis of the Management domain
 
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
 
portion of their O/R Name until arrival at the recipient MD.  At
Line 1,131: Line 1,077:
 
route to the recipient UA.  Internal routing within a MD is the
 
route to the recipient UA.  Internal routing within a MD is the
 
responsibility of each MD.
 
responsibility of each MD.
−
=== ESnet X.400 Logical Backbone ===
+
 
 +
=== ESnet X.400 Logical Backbone ===
 +
 
 
Currently within the ESnet community message handling services are
 
Currently within the ESnet community message handling services are
 
implemented with a number of different mail products, resulting in
 
implemented with a number of different mail products, resulting in
Line 1,141: Line 1,089:
 
support MAIL-11 and QuickMail locally.  Identically, this scenario
 
support MAIL-11 and QuickMail locally.  Identically, this scenario
 
exists for CEBAF.
 
exists for CEBAF.
 +
 
To alleviate this problem, a logical X.400 backbone must be
 
To alleviate this problem, a logical X.400 backbone must be
 
established through out the entire ESnet backbone.  Then, each ESnet
 
established through out the entire ESnet backbone.  Then, each ESnet
Line 1,148: Line 1,097:
 
term goals is to establish X.400 as the "common denominator" between
 
term goals is to establish X.400 as the "common denominator" between
 
directly connected ESnet backbone sites.
 
directly connected ESnet backbone sites.
−
=== Naming Structure ===
+
 
 +
=== Naming Structure ===
 +
 
 
The name-spaces for X.500 and X.400 are completely different and are
 
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
 
structured to meet different needs.  The X.500 name-space is
Line 1,154: Line 1,105:
 
X.400 ORname is used to forward an X.400 message through several
 
X.400 ORname is used to forward an X.400 message through several
 
"levels" of MTAs (X.400 Message Transfer Agents).
 
"levels" of MTAs (X.400 Message Transfer Agents).
 +
 
ESnet backbone sites will participate in the X.400 environment
 
ESnet backbone sites will participate in the X.400 environment
 
through one of two options; either participating in the ESnet Private
 
through one of two options; either participating in the ESnet Private
 
Management Domain (PRMD) or operating a site PRMD.  For most sites,
 
Management Domain (PRMD) or operating a site PRMD.  For most sites,
 
utilizing the ESnet PRMD will be the simpler and preferable choice.
 
utilizing the ESnet PRMD will be the simpler and preferable choice.
−
==== Participating in the ESnet Private Management Domain ====
+
 
 +
==== Participating in the ESnet Private Management Domain ====
 +
 
 
ESnet backbone sites participating in the ESnet PRMD will have an
 
ESnet backbone sites participating in the ESnet PRMD will have an
 
X.400 name syntax as follows:
 
X.400 name syntax as follows:
 +
 
                 /.../O=<site>/PRMD=ESnet/ADMD= /C=US/
 
                 /.../O=<site>/PRMD=ESnet/ADMD= /C=US/
 +
 
A few examples of a possible X.400 ORnames using the above syntax
 
A few examples of a possible X.400 ORnames using the above syntax
 
are:
 
are:
−
 
−
 
−
 
−
 
−
 
−
 
−
 
  
 
       /PN=Smith/OU=Computations/O=LLNL/PRMD=ESnet/ADMD= /C=US/
 
       /PN=Smith/OU=Computations/O=LLNL/PRMD=ESnet/ADMD= /C=US/
 
         /PN=Jones/OU=Physics/O=PPPL/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
 
These sites will operate an MTA at the /O=<organization> level in the
 
name hierarchy.
 
name hierarchy.
−
==== Operating a Site Private Management Domain ====
+
 
 +
==== Operating a Site Private Management Domain ====
 +
 
 
ESnet backbone sites which operate a PRMD will have an X.400 name
 
ESnet backbone sites which operate a PRMD will have an X.400 name
 
syntax as follows:
 
syntax as follows:
 +
 
                 /.../O=<org>/PRMD=<site>/ADMD= /C=US/
 
                 /.../O=<org>/PRMD=<site>/ADMD= /C=US/
 +
 
A few examples of a possible X.400 ORnames using the above syntax
 
A few examples of a possible X.400 ORnames using the above syntax
 
are:
 
are:
 +
 
           /PN=Smith/O=Computations/PRMD=LLNL/ADMD= /C=US/
 
           /PN=Smith/O=Computations/PRMD=LLNL/ADMD= /C=US/
 
             /PN=Jones/O=Physics/PRMD=PPPL/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
 
These sites will operate an MTA at the /PRMD=<PRMD> level in the name
 
hierarchy.  This MTA will peer with the ESnet PRMD MTA.
 
hierarchy.  This MTA will peer with the ESnet PRMD MTA.
−
==== Detailed Name Structure ====
+
 
 +
==== Detailed Name Structure ====
 +
 
 
GOSIP places several limits on allowable ORnames.  After the
 
GOSIP places several limits on allowable ORnames.  After the
 
/O=<organization> name, up to four levels of
 
/O=<organization> name, up to four levels of
 
/OU=<organizational_unit> names are allowed.  The ORname string is
 
/OU=<organizational_unit> names are allowed.  The ORname string is
 
then completed with the /PN=<personal_name> field.
 
then completed with the /PN=<personal_name> field.
 +
 
All ORname fields must use characters from the ISO printable
 
All ORname fields must use characters from the ISO printable
 
character set.  Additionally, the following name length restrictions
 
character set.  Additionally, the following name length restrictions
 
apply:
 
apply:
 +
 
             PRMD Names                    16 characters
 
             PRMD Names                    16 characters
 
             Organization Names            64 characters
 
             Organization Names            64 characters
 
             Organizational Unit Names    32 characters
 
             Organizational Unit Names    32 characters
 
             Personal Names                64 characters
 
             Personal Names                64 characters
 +
 
   NOTE:  A 40 character limit for Personal Names is now being
 
   NOTE:  A 40 character limit for Personal Names is now being
 
           studied by the CCITT.
 
           studied by the CCITT.
 +
 
Within these name constraints, the architecting of an organization's
 
Within these name constraints, the architecting of an organization's
 
name space is a local matter.  Sites are encouraged to consider ease
 
name space is a local matter.  Sites are encouraged to consider ease
 
of use and stability when determining their naming structure.
 
of use and stability when determining their naming structure.
−
===  X.400 Routing ===
 
−
In the IP environment a SMTP MTA could use the Domain Name Service
 
−
 
−
 
−
 
−
 
  
 +
=== 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
 
(DNS) to locate connection information for the host closest to the
Line 1,221: Line 1,179:
 
distribution effort to ensure a quick and reliable update of these
 
distribution effort to ensure a quick and reliable update of these
 
tables.
 
tables.
 +
 
The current thinking on the problem of X.400 routing is to decompose
 
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
 
the X.400 address space into a hierarchy, with each node in this
Line 1,226: Line 1,185:
 
nodes have been commonly called Well Known Entry Points (WEPs).  Each
 
nodes have been commonly called Well Known Entry Points (WEPs).  Each
 
of these WEPs represent one X.400 MHS domain.  For example:
 
of these WEPs represent one X.400 MHS domain.  For example:
 +
 
   /O=LBL/PRMD=ESnet/ADMD= /C=US/
 
   /O=LBL/PRMD=ESnet/ADMD= /C=US/
 
   /O=NERSC/PRMD=ESnet/ADMD= /C=US/
 
   /O=NERSC/PRMD=ESnet/ADMD= /C=US/
Line 1,231: Line 1,191:
 
   /PRMD=ANL/ADMD= /C=US/
 
   /PRMD=ANL/ADMD= /C=US/
 
   /PRMD=PNL/ADMD= /C=US/
 
   /PRMD=PNL/ADMD= /C=US/
 +
 
To minimize the number of hops between Originators and Recipients it
 
To minimize the number of hops between Originators and Recipients it
 
is the current recommendation of the X.400 community that every PRMD
 
is the current recommendation of the X.400 community that every PRMD
 
peer with all other PRMDs.
 
peer with all other PRMDs.
 +
 
The ESnet backbone will provide connectivity between multiple PRMDs
 
The ESnet backbone will provide connectivity between multiple PRMDs
 
(the ESnet PRMD and any site operated PRMDs), each with associated
 
(the ESnet PRMD and any site operated PRMDs), each with associated
Line 1,247: Line 1,209:
 
administrators should retrieve this new routing information and
 
administrators should retrieve this new routing information and
 
update their MTAs within 10 working days.
 
update their MTAs within 10 working days.
 +
 
The well-known entry point MTA for each PRMD can route down to an
 
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
 
Organizational level MTA or laterally to the well-known entry point
 
of a peer PRMD MTA.
 
of a peer PRMD MTA.
 +
 
For example, the ESnet MTA would route a message with the address:
 
For example, the ESnet MTA would route a message with the address:
 +
 
             /PN=Funk/OU=CS/O=PPPL/PRMD=ESnet/ADMD= /C=US/
 
             /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
 
to a well-known entry point for PPPL (O=PPPL).  PPPL must own and
Line 1,264: Line 1,222:
 
X.400 messages from the ESnet MTA.  Thus, the interpretation of
 
X.400 messages from the ESnet MTA.  Thus, the interpretation of
 
remaining "/PN=Funk/OU=CS" is left to the PPPL MTA to route.
 
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)
 
Mail sent from PPPL's MTA would be routed to the ESnet's MTA (PRMD)
 
to be eventually routed to its destination.
 
to be eventually routed to its destination.
 +
 
The ESnet MTA will also route to peer MTAs which are well-known entry
 
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
 
points for other PRMDs (e.g. ESnet backbone site PRMDs, XNREN, Hughes
 
Air Craft, NASA, CDC).  For example, the ESnet MTA would route a
 
Air Craft, NASA, CDC).  For example, the ESnet MTA would route a
 
message with the address:
 
message with the address:
 +
 
             /PN=Smith/OU=MS/O=RL/PRMD=PNL/ADMD= /C=US/
 
             /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
 
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
 
operate their own X.400 MTA, and it must be configured to accept
Line 1,276: Line 1,238:
 
Thus, the interpretation of the remaining "/PN=SMITH/OU=MS/O=RL" is
 
Thus, the interpretation of the remaining "/PN=SMITH/OU=MS/O=RL" is
 
left to the PNL MTA to route.
 
left to the PNL MTA to route.
 +
 
Mail sent from PNL's MTA (PRMD) would be routed to the well-known
 
Mail sent from PNL's MTA (PRMD) would be routed to the well-known
 
entry point for the PRMD indicated in the destination address.
 
entry point for the PRMD indicated in the destination address.
 +
 
Additionally, a site operated PRMD must be able to route mail to any
 
Additionally, a site operated PRMD must be able to route mail to any
 
other peer-PRMD within the ESnet community.
 
other peer-PRMD within the ESnet community.
−
==== Responsibilities in Operating an X.400 PRMD MTA ====
+
 
 +
==== Responsibilities in Operating an X.400 PRMD MTA ====
 +
 
 
If the X.400 world were to operate exactly as the standard
 
If the X.400 world were to operate exactly as the standard
 
recommends, PRMDs would only peer with other PRMDs when connectivity
 
recommends, PRMDs would only peer with other PRMDs when connectivity
Line 1,287: Line 1,253:
 
subscribe to an ADMD service and will only be reachable through PRMD
 
subscribe to an ADMD service and will only be reachable through PRMD
 
peering.
 
peering.
 +
 
Most communities, such as the ESnet, desire the fullest PRMD
 
Most communities, such as the ESnet, desire the fullest PRMD
 
interconnectivity possible to minimize the need for ADMD services.
 
interconnectivity possible to minimize the need for ADMD services.
Line 1,292: Line 1,259:
 
achieving large scale peering among PRMD operators within the
 
achieving large scale peering among PRMD operators within the
 
community.
 
community.
 +
 
Work is continuing in the IETF X.400 Operations Working Group to
 
Work is continuing in the IETF X.400 Operations Working Group to
 
produce an RFC that specifies the operational requirements that must
 
produce an RFC that specifies the operational requirements that must
Line 1,298: Line 1,266:
 
Development X.400 Service", this document is listed in Appendix G.
 
Development X.400 Service", this document is listed in Appendix G.
 
ESnet will comply with all the requirements outlined in this
 
ESnet will comply with all the requirements outlined in this
−
 
−
 
−
 
−
 
−
 
−
 
  
 
document.  It is the recommendation that all ESnet PRMDs follow the
 
document.  It is the recommendation that all ESnet PRMDs follow the
 
requirements specified in this document.
 
requirements specified in this document.
 +
 
As an overview, this document specifies that each PRMD will provide
 
As an overview, this document specifies that each PRMD will provide
 
at least one WEP and that all PRMDs must be interconnected.  There
 
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
 
are a number of PRMDs in the International X.400 service that have
 
different communication stack requirements.  For example:
 
different communication stack requirements.  For example:
 +
 
                       Stack 1    Stack 2    Stack 3    Stack 4
 
                       Stack 1    Stack 2    Stack 3    Stack 4
 
                       -------    -------    -------    -------
 
                       -------    -------    -------    -------
 
   Transport Layer 4        TP0        TP4    RFC-1006        TP0
 
   Transport Layer 4        TP0        TP4    RFC-1006        TP0
 
   Network Service 1-3    X.25        CLNS      TCP/IP        CONS
 
   Network Service 1-3    X.25        CLNS      TCP/IP        CONS
 +
 
To meet the requirement that all PRMDs must be interconnected a PRMD
 
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
 
must support one or more of the above stacks.  For stacks that are
Line 1,320: Line 1,285:
 
relay messages to a Management Domain that does support the other
 
relay messages to a Management Domain that does support the other
 
stacks.
 
stacks.
 +
 
The PRMD requirements also suggest that PRMDs support downgrading of
 
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
 
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
 
Internet Mail service.  This means the PRMD must maintain an Internet
 
Mail/X.400 gateway.
 
Mail/X.400 gateway.
 +
 
In all cases, members of the ESnet community who operate a PRMD
 
In all cases, members of the ESnet community who operate a PRMD
 
should notify ESnet of the WEP and MTA information required to
 
should notify ESnet of the WEP and MTA information required to
 
perform peering.
 
perform peering.
−
==== Responsibilities in Operating an X.400 Organizational MTA ====
+
 
 +
==== Responsibilities in Operating an X.400 Organizational MTA ====
 +
 
 
ESnet will provide PRMD service to the ESnet community.  ESnet will
 
ESnet will provide PRMD service to the ESnet community.  ESnet will
 
peer with the other PRMDs in the International X.400 service and
 
peer with the other PRMDs in the International X.400 service and
Line 1,336: Line 1,305:
 
stacks provided by it associated PRMD.  But in all cases, the site
 
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.
 
will need to provide a WEP and register/list their MTA(s) with ESnet.
−
=== Services Provided by ESnet ===
+
 
 +
=== Services Provided by ESnet ===
 +
 
 
ESnet will provide PRMD service to those members of the ESnet
 
ESnet will provide PRMD service to those members of the ESnet
 
community who desire it.  ESnet will peer with other PRMDs in the
 
community who desire it.  ESnet will peer with other PRMDs in the
Line 1,342: Line 1,313:
 
provide a WEP for the ESnet community; the intent is to provide the
 
provide a WEP for the ESnet community; the intent is to provide the
 
fullest PRMD level X.400 services.
 
fullest PRMD level X.400 services.
 +
 
ESnet will deploy two, PRMD level, X.400 MTAs in geographically
 
ESnet will deploy two, PRMD level, X.400 MTAs in geographically
−
 
−
 
−
 
−
 
−
 
−
 
  
 
disperse locations.  These MTAs will be able to forward mail for
 
disperse locations.  These MTAs will be able to forward mail for
 
directly connected ESnet backbone sites, as well as to and from the
 
directly connected ESnet backbone sites, as well as to and from the
 
peered PRMDs.
 
peered PRMDs.
−
==== X.400 Operations Mailing List ====
+
 
 +
==== X.400 Operations Mailing List ====
 +
 
 
ESnet will provide an X.400 operations mailer for announcements and
 
ESnet will provide an X.400 operations mailer for announcements and
 
to allow the sharing of X.400 operational information in the ESnet
 
to allow the sharing of X.400 operational information in the ESnet
 
community.
 
community.
 +
 
   General discussion:  [email protected]
 
   General discussion:  [email protected]
 
   To subscribe:        [email protected]
 
   To subscribe:        [email protected]
−
==== MTA Routing Table on ESnet Information Server ====
+
 
 +
==== MTA Routing Table on ESnet Information Server ====
 +
 
 
ESnet will maintain forwarding information about ESnet community MTAs
 
ESnet will maintain forwarding information about ESnet community MTAs
 
at the /PRMD=<PRMD> or /O=<organization> levels (depending on what
 
at the /PRMD=<PRMD> or /O=<organization> levels (depending on what
Line 1,366: Line 1,337:
 
This information will be made available in a machine independent
 
This information will be made available in a machine independent
 
format on the ESnet Information Server.
 
format on the ESnet Information Server.
−
==== MTA Routing Table Format ====
+
 
 +
==== MTA Routing Table Format ====
 +
 
 
The ESnet staff will determine the details of information format,
 
The ESnet staff will determine the details of information format,
 
update frequency, obtaining, and disseminating the information based
 
update frequency, obtaining, and disseminating the information based
 
on operational experience and constraints.
 
on operational experience and constraints.
−
==== Gateway Services and Multiprotocol Stack Support ====
+
 
 +
==== Gateway Services and Multiprotocol Stack Support ====
 +
 
 
The ESnet MTAs will minimally support bidirectional SMTP-X.400 mail
 
The ESnet MTAs will minimally support bidirectional SMTP-X.400 mail
 
gateway capabilities, and will operate over the OSI CLNS protocol (as
 
gateway capabilities, and will operate over the OSI CLNS protocol (as
Line 1,376: Line 1,351:
 
of mail protocol gateway functions will be governed by the ESnet
 
of mail protocol gateway functions will be governed by the ESnet
 
staff.
 
staff.
 +
 
Backbone site MTAs which service ORnames at the /O=<site> level under
 
Backbone site MTAs which service ORnames at the /O=<site> level under
 
the ESnet PRMD must utilize one of the ESnet PRMD supported protocol
 
the ESnet PRMD must utilize one of the ESnet PRMD supported protocol
 
stacks.  This requirement assures that all users of the ESnet PRMD
 
stacks.  This requirement assures that all users of the ESnet PRMD
 
will be able to communicate to one another via the ESnet PRMD MTA.
 
will be able to communicate to one another via the ESnet PRMD MTA.
 +
 
Backbone site MTAs which service ORnames in PRMDs other than
 
Backbone site MTAs which service ORnames in PRMDs other than
 
/PRMD=ESnet must utilize the OSI CLNS stack for GOSIP conformance.
 
/PRMD=ESnet must utilize the OSI CLNS stack for GOSIP conformance.
Line 1,386: Line 1,363:
 
PRMD.
 
PRMD.
  
 +
==== Registering/Listing your PRMD or Organizational MTA with ESnet ====
  
−
 
−
 
−
 
−
 
−
 
−
 
−
 
−
====  Registering/Listing your PRMD or Organizational MTA with ESnet ====
 
 
To provide for the connection and routing requirements in X.400 you
 
To provide for the connection and routing requirements in X.400 you
 
will need to register/list your MTA with ESnet.  This information
 
will need to register/list your MTA with ESnet.  This information
Line 1,405: Line 1,375:
 
working draft, see Appendix G.  It describes a machine independent
 
working draft, see Appendix G.  It describes a machine independent
 
form for distribution of X.400 information.
 
form for distribution of X.400 information.
 +
 
There are three tables that must be maintained and exchanged by the
 
There are three tables that must be maintained and exchanged by the
 
top level WEPS.
 
top level WEPS.
 +
 
1.  The Community Document
 
1.  The Community Document
 +
 
2.  The WEP Document
 
2.  The WEP Document
 +
 
3.  The Domain Document
 
3.  The Domain Document
 +
 
ESnet will submit these documents to the International X.400
 
ESnet will submit these documents to the International X.400
 
community on behalf of the ESnet Community.  If an ESnet PRMD wishes
 
community on behalf of the ESnet Community.  If an ESnet PRMD wishes
 
to peer with the International PRMDs they will need to submit these
 
to peer with the International PRMDs they will need to submit these
 
documents to that community.
 
documents to that community.
 +
 
The Community document is used to list the central coordination point
 
The Community document is used to list the central coordination point
 
and file server where all MHS documents will be stored.  It also
 
and file server where all MHS documents will be stored.  It also
Line 1,422: Line 1,398:
 
with the International X.400 service then they must submit this form
 
with the International X.400 service then they must submit this form
 
to that community.
 
to that community.
 +
 
Each ESnet MHS domain will need to submit a WEP and Domain Document
 
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
 
to ESnet.  The WEP document is used to list the WEPs used by an ESnet
Line 1,429: Line 1,406:
 
service.  The WEP document consists of a list of WEPs, with the
 
service.  The WEP document consists of a list of WEPs, with the
 
following information for each one:
 
following information for each one:
 +
 
o  The MTA Name
 
o  The MTA Name
 +
 
o  Password
 
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
  
−
 
−
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
 
The Domain Document specifies all the X.400 domains managed by a
 
site.  It indicates the person responsible and which WEP services
 
site.  It indicates the person responsible and which WEP services
 
which Domain.  This document contains the following information
 
which Domain.  This document contains the following information
 
repeated for each Domain:
 
repeated for each Domain:
 +
 
o  X.400 Domain
 
o  X.400 Domain
 +
 
o  Point of Contact
 
o  Point of Contact
 +
 
o  Relaying WEP(s)
 
o  Relaying WEP(s)
−
=== X.400 Message Routing Between ADMDS and PRMDS ===
+
 
 +
=== X.400 Message Routing Between ADMDS and PRMDS ===
 +
 
 
While ESnet will provide X.400 routing service for systems, it cannot
 
While ESnet will provide X.400 routing service for systems, it cannot
 
provide routing via commercial X.400 carriers at this time.  The
 
provide routing via commercial X.400 carriers at this time.  The
Line 1,461: Line 1,444:
 
and the provision of a charging mechanism to charge member sites is
 
and the provision of a charging mechanism to charge member sites is
 
not currently contemplated.
 
not currently contemplated.
−
=== X.400 Registration Requirements ===
+
 
 +
=== X.400 Registration Requirements ===
 +
 
 
It is recommended by the CCITT that all X.400 PRMD names be
 
It is recommended by the CCITT that all X.400 PRMD names be
 
nationally unique.  This is a current CCITT agreement and allows
 
nationally unique.  This is a current CCITT agreement and allows
Line 1,467: Line 1,452:
 
required, registration should be performed through an appropriate
 
required, registration should be performed through an appropriate
 
registration authority (such as ANSI).
 
registration authority (such as ANSI).
 +
 
X.400 organization names must be unique within a PRMD.  There is no
 
X.400 organization names must be unique within a PRMD.  There is no
 
need for national uniqueness.  Registration of an X.400 organization
 
need for national uniqueness.  Registration of an X.400 organization
 
name should be conducted through the PRMD operator.
 
name should be conducted through the PRMD operator.
 +
 
The registration of X.400 names below the organization level are
 
The registration of X.400 names below the organization level are
 
usually a local matter.  Uniqueness within the context of a superior
 
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.
  
 +
=== Future X.400 Issues to be Considered ===
  
 +
==== X.400 Mail Routing to International DOE Researchers ====
  
−
 
−
 
−
name should always be maintained.
 
−
See Section 4 for a more complete description of OSI registration
 
−
issues and procedures.
 
−
===  Future X.400 Issues to be Considered ===
 
−
====  X.400 Mail Routing to International DOE Researchers ====
 
 
Currently there are DOE researchers located in Switzerland, Japan,
 
Currently there are DOE researchers located in Switzerland, Japan,
 
Germany, China and Brazil.  PRMD level connectivity to these
 
Germany, China and Brazil.  PRMD level connectivity to these
Line 1,489: Line 1,474:
 
chartered to pay for commercial X.400 services on behalf of the ESnet
 
chartered to pay for commercial X.400 services on behalf of the ESnet
 
community, "buying" this service is not a viable option.
 
community, "buying" this service is not a viable option.
 +
 
There are efforts taking place to provide international X.400 service
 
There are efforts taking place to provide international X.400 service
 
over the (international) Internet.  Once this becomes fully
 
over the (international) Internet.  Once this becomes fully
Line 1,494: Line 1,480:
 
this provides the X.400 connectivity needed to support the DOE
 
this provides the X.400 connectivity needed to support the DOE
 
researchers located abroad.
 
researchers located abroad.
−
==== X.400 (1984) and X.400 (1988) ====
+
 
 +
==== X.400 (1984) and X.400 (1988) ====
 +
 
 
The ESnet MTAs will initially support the 1984 version of the X.400
 
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
 
standard.  As the use of 1988 X.400 becomes more prevalent, support
Line 1,501: Line 1,489:
 
also have so support "downgrading" to 1984 X.400 to ensure reliable
 
also have so support "downgrading" to 1984 X.400 to ensure reliable
 
X.400 mail delivery to the ESnet community.
 
X.400 mail delivery to the ESnet community.
−
==== X.400 Interaction with X.500 ====
+
 
 +
==== X.400 Interaction with X.500 ====
 +
 
 
This is discussed in Section 2.10.2.
 
This is discussed in Section 2.10.2.
−
== OSI Name Registration and Issues ==
+
 
 +
== OSI Name Registration and Issues ==
 +
 
 
Implementing OSI services requires that certain information objects
 
Implementing OSI services requires that certain information objects
 
(e.g., people, information processing systems and applications) must
 
(e.g., people, information processing systems and applications) must
Line 1,509: Line 1,501:
 
be defined by a variety of organizations, e.g., ISO/IEC, CCITT,
 
be defined by a variety of organizations, e.g., ISO/IEC, CCITT,
 
commercial, and government.
 
commercial, and government.
 +
 
To meet this requirement ISO/IEC and CCITT have established a
 
To meet this requirement ISO/IEC and CCITT have established a
 
hierarchical structure of names (a tree).  The top level of the
 
hierarchical structure of names (a tree).  The top level of the
Line 1,516: Line 1,509:
 
naming-domain to another (lower level) registration authority, thus
 
naming-domain to another (lower level) registration authority, thus
  
 +
forming the tree.
  
−
 
−
 
−
 
−
 
−
 
−
forming the tree.
 
 
Each object can be given a unique and unambiguous name by registering
 
Each object can be given a unique and unambiguous name by registering
 
the object's name with an OSI registration authority at an
 
the object's name with an OSI registration authority at an
 
appropriate level in the naming tree.
 
appropriate level in the naming tree.
 +
 
OSI name registration authorities and their procedures are expected
 
OSI name registration authorities and their procedures are expected
 
to change over time.  Since names are intended to be stable, these
 
to change over time.  Since names are intended to be stable, these
 
changes (hopefully!) will have minimal impact on existing OSI name
 
changes (hopefully!) will have minimal impact on existing OSI name
 
registrations.
 
registrations.
 +
 
This section describes the role of OSI registration authorities, the
 
This section describes the role of OSI registration authorities, the
 
difference between a "registration" and a "notification", and sources
 
difference between a "registration" and a "notification", and sources
Line 1,536: Line 1,526:
 
(ANSI), the General Services Administration (GSA), and the U.S.
 
(ANSI), the General Services Administration (GSA), and the U.S.
 
Department of Energy (U.S. DOE); are given.
 
Department of Energy (U.S. DOE); are given.
 +
 
Registration of a name often requires stating a "right" to that name.
 
Registration of a name often requires stating a "right" to that name.
 
However, an OSI name registration does not guarantee legal name
 
However, an OSI name registration does not guarantee legal name
Line 1,542: Line 1,533:
 
Patent and Trademark Office (PTO) (potentially useful in asserting or
 
Patent and Trademark Office (PTO) (potentially useful in asserting or
 
defending name rights) is given below.
 
defending name rights) is given below.
−
=== Registration Authorities ===
+
 
 +
=== Registration Authorities ===
 +
 
 
OSI names are obtained through OSI name registration authorities by a
 
OSI names are obtained through OSI name registration authorities by a
 
registration process.  The selection of which particular registration
 
registration process.  The selection of which particular registration
Line 1,549: Line 1,542:
 
by each registration authority, and the applicability rules (will
 
by each registration authority, and the applicability rules (will
 
they service your request) of each registration authority.
 
they service your request) of each registration authority.
 +
 
An OSI name registration authority allocates OSI names from the
 
An OSI name registration authority allocates OSI names from the
 
particular naming-domain it controls.  Every registration authority
 
particular naming-domain it controls.  Every registration authority
 
can trace its naming authority to its parent registration authority,
 
can trace its naming authority to its parent registration authority,
 
and ultimately to the top (global) level of the naming hierarchy.
 
and ultimately to the top (global) level of the naming hierarchy.
−
=== Registration Versus Notification ===
+
 
 +
=== Registration Versus Notification ===
 +
 
 
Registering an OSI name guarantees its uniqueness and lack of
 
Registering an OSI name guarantees its uniqueness and lack of
 
ambiguity. For a name to be useful however, other parties (besides
 
ambiguity. For a name to be useful however, other parties (besides
 
the registration authority) will need to be notified of the name and
 
the registration authority) will need to be notified of the name and
 
its usage.
 
its usage.
 +
 
There is a clear distinction between registration (obtaining an OSI
 
There is a clear distinction between registration (obtaining an OSI
 
name) and notification (informing others of a name and its use).
 
name) and notification (informing others of a name and its use).
−
 
−
 
−
 
−
 
−
 
−
 
  
 
Often the term "registration" is used to describe both activities,
 
Often the term "registration" is used to describe both activities,
 
this is a potential source of confusion.
 
this is a potential source of confusion.
 +
 
For example, NADF and PSI (see Section 2) are not OSI registration
 
For example, NADF and PSI (see Section 2) are not OSI registration
 
authorities.  NADF may operate state registration authorities in the
 
authorities.  NADF may operate state registration authorities in the
Line 1,574: Line 1,566:
 
operates an X.500 pilot project and needs to be notified of
 
operates an X.500 pilot project and needs to be notified of
 
registered names when organizations join their pilot.
 
registered names when organizations join their pilot.
 +
 
X.400 ADMD operators are also not OSI registration authorities,
 
X.400 ADMD operators are also not OSI registration authorities,
 
although they accept notification of X.400 PRMD names used by their
 
although they accept notification of X.400 PRMD names used by their
 
customers.
 
customers.
 +
 
The PTO is not an OSI registration authority.  PTO names have no
 
The PTO is not an OSI registration authority.  PTO names have no
 
meaning in an OSI context.
 
meaning in an OSI context.
−
=== Sources of Nationally Unique Name Registration ===
+
 
 +
=== Sources of Nationally Unique Name Registration ===
 +
 
 
There are four potential sources of nationally unique names which are
 
There are four potential sources of nationally unique names which are
 
of interest to the ESnet community.  These are ANSI, GSA, U.S. DOE
 
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
 
and the states.  An overview of the ANSI, GSA, and U.S. DOE
 
procedures are given in later sections.
 
procedures are given in later sections.
 +
 
In order to maintain national uniqueness "constructed name syntax" is
 
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
 
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
 
shown below, "name" is the name presented to the registration
 
authority for registration.
 
authority for registration.
 +
 
1.  ANSI names are of the form "name".
 
1.  ANSI names are of the form "name".
 +
 
2.  GSA names are of the form "GOV+name".
 
2.  GSA names are of the form "GOV+name".
 +
 
3.  U.S. DOE names are of the form "GOV+USDOE+name".
 
3.  U.S. DOE names are of the form "GOV+USDOE+name".
 +
 
4.  State names are of the form "CA+name" (using California).
 
4.  State names are of the form "CA+name" (using California).
 +
 
State name registration authorities are not in operation at this
 
State name registration authorities are not in operation at this
 
time.  The use of U.S. DOE as a nationally unique name registration
 
time.  The use of U.S. DOE as a nationally unique name registration
 
source is not recommended due to the awkwardness of a double
 
source is not recommended due to the awkwardness of a double
 
constructed name.
 
constructed name.
−
=== How to Apply for ANSI Organization Names ===
+
 
 +
=== How to Apply for ANSI Organization Names ===
 +
 
 
ANSI is the root U.S. source of OSI recognized nationally unique
 
ANSI is the root U.S. source of OSI recognized nationally unique
 
organization names.  ANSI registration costs $2500 and results in
 
organization names.  ANSI registration costs $2500 and results in
Line 1,602: Line 1,606:
 
names may be used for a variety of purposes in X.400, X.500, and
 
names may be used for a variety of purposes in X.400, X.500, and
 
other OSI services.
 
other OSI services.
−
 
−
 
−
 
−
 
−
 
−
 
  
 
For ANSI OSI organization name registration forms and instructions,
 
For ANSI OSI organization name registration forms and instructions,
 
you should send your request to:
 
you should send your request to:
 +
 
             American National Standards Institute, Inc.
 
             American National Standards Institute, Inc.
 
             Attn:  Beth Somerville
 
             Attn:  Beth Somerville
Line 1,617: Line 1,616:
 
             New York, NY  10036
 
             New York, NY  10036
 
             Phone:  (212) 642-4976
 
             Phone:  (212) 642-4976
 +
 
ANSI registration procedures include a 90 day public review period
 
ANSI registration procedures include a 90 day public review period
 
during which name requests can be easily challenged.
 
during which name requests can be easily challenged.
 +
 
There is a mechanism to forward ANSI requests to the GSA, it is
 
There is a mechanism to forward ANSI requests to the GSA, it is
 
discussed in the GSA section below.
 
discussed in the GSA section below.
−
=== How to Apply for GSA Organization Names ===
+
 
 +
=== How to Apply for GSA Organization Names ===
 +
 
 
GSA is the registration authority for government use of GOSIP, their
 
GSA is the registration authority for government use of GOSIP, their
 
registration services are free for federal government organizations.
 
registration services are free for federal government organizations.
Line 1,627: Line 1,630:
 
limited to 16 characters.  By agreement with ANSI, these GSA assigned
 
limited to 16 characters.  By agreement with ANSI, these GSA assigned
 
names are national unique.
 
names are national unique.
 +
 
For GSA OSI Organization Name registration forms and instructions,
 
For GSA OSI Organization Name registration forms and instructions,
 
you should send your request to:
 
you should send your request to:
 +
 
               General Services Administration
 
               General Services Administration
 
               Office of Telecommunications Services
 
               Office of Telecommunications Services
Line 1,634: Line 1,639:
 
               18th and F Streets, N.W.
 
               18th and F Streets, N.W.
 
               Washington, D.C. 20405
 
               Washington, D.C. 20405
−
==== GSA Designated Agency Representatives ====
+
 
 +
==== GSA Designated Agency Representatives ====
 +
 
 
When preparing the GSA registration form a designated agency
 
When preparing the GSA registration form a designated agency
 
representative must sign where it says "Registration Official Name
 
representative must sign where it says "Registration Official Name
 
and Signature".  GSA will refuse requests missing this signature.
 
and Signature".  GSA will refuse requests missing this signature.
 +
 
The GSA designated Agency Representative for the Department of Energy
 
The GSA designated Agency Representative for the Department of Energy
 
is:
 
is:
−
 
−
 
−
 
−
 
−
 
−
 
−
 
−
 
−
 
−
 
−
 
−
 
−
 
  
 
                 Steve Hackman
 
                 Steve Hackman
Line 1,662: Line 1,657:
 
                 Office FAX:    (301) 903-4125
 
                 Office FAX:    (301) 903-4125
 
                 E-Mail:  [email protected]
 
                 E-Mail:  [email protected]
−
==== Forwarding of ANSI Registrations to GSA ====
+
 
 +
==== Forwarding of ANSI Registrations to GSA ====
 +
 
 
ANSI registration requests can be forwarded automatically to the GSA.
 
ANSI registration requests can be forwarded automatically to the GSA.
 
This is the equivalent of registering with both ANSI and GSA.  The
 
This is the equivalent of registering with both ANSI and GSA.  The
 
result is two nationally unique OSI name registrations, "name" from
 
result is two nationally unique OSI name registrations, "name" from
 
ANSI and "GOV+name" from GSA.
 
ANSI and "GOV+name" from GSA.
 +
 
There is no GOSIP requirement for GSA registration but many feel the
 
There is no GOSIP requirement for GSA registration but many feel the
 
additional GSA registration may be useful.
 
additional GSA registration may be useful.
 +
 
Assuming your organization is a federal government organization,
 
Assuming your organization is a federal government organization,
 
answer the last three questions on the ANSI registration form as
 
answer the last three questions on the ANSI registration form as
 
shown below:
 
shown below:
 +
 
1.  Do you wish the information supplied in the request to remain
 
1.  Do you wish the information supplied in the request to remain
 
     confidential?  NO.
 
     confidential?  NO.
 +
 
2.  Do you wish to have your organization name registered with the
 
2.  Do you wish to have your organization name registered with the
 
     U.S. GOSIP Registration Authority (a.k.a. GSA)?  YES.
 
     U.S. GOSIP Registration Authority (a.k.a. GSA)?  YES.
 +
 
3.  Is your organization an organization of the Federal Government?
 
3.  Is your organization an organization of the Federal Government?
 
     YES.
 
     YES.
 +
 
You must indicate on the application form the approval of the GSA
 
You must indicate on the application form the approval of the GSA
 
designated agency representative (Steve Hackman).  He does not sign
 
designated agency representative (Steve Hackman).  He does not sign
 
as "Signature of Requestor", but some notation of his approval must
 
as "Signature of Requestor", but some notation of his approval must
 
be attached or GSA will reject the forwarded application.
 
be attached or GSA will reject the forwarded application.
−
=== How to Apply for U.S. DOE Organization Names ===
+
 
 +
=== How to Apply for U.S. DOE Organization Names ===
 +
 
 
ESnet sites are encouraged to review the DOE GOSIP procedures and
 
ESnet sites are encouraged to review the DOE GOSIP procedures and
 
guidelines in planning their GOSIP activities.  This document does
 
guidelines in planning their GOSIP activities.  This document does
 
not conflict with current DOE GOSIP policies.
 
not conflict with current DOE GOSIP policies.
 +
 
DOE can assign nationally unique names which are prefixed by the
 
DOE can assign nationally unique names which are prefixed by the
 
string "GOV+USDOE+".  Use of this name source is not recommended;
 
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
 
there is no apparent advantage in using U.S. DOE over GSA as a source
 
of nationally unique names.
 
of nationally unique names.
−
 
−
 
−
 
−
 
−
 
−
 
−
 
  
 
Copies of current U.S. DOE GOSIP policies, guidelines, and
 
Copies of current U.S. DOE GOSIP policies, guidelines, and
 
registration forms may be obtained through site DOE naming
 
registration forms may be obtained through site DOE naming
 
authorities or Steve Hackman.
 
authorities or Steve Hackman.
−
=== Why Apply for a Trademark with the PTO? ===
+
 
 +
=== Why Apply for a Trademark with the PTO? ===
 +
 
 
Legal issues may arise concerning the rights to use a desired name.
 
Legal issues may arise concerning the rights to use a desired name.
 
OSI name registrations are not intended to "legally protect" name
 
OSI name registrations are not intended to "legally protect" name
 
usage rights; that is not their function.
 
usage rights; that is not their function.
 +
 
Consultation with legal experts concerning the rights to use a name
 
Consultation with legal experts concerning the rights to use a name
 
being registered is strongly advised, this recommendation does not
 
being registered is strongly advised, this recommendation does not
 
offer specific legal guidance.  Applying for a trademark may be
 
offer specific legal guidance.  Applying for a trademark may be
 
considered as a means to assert or protect the rights to a name.
 
considered as a means to assert or protect the rights to a name.
 +
 
Per the PTO trademark application instructions there may be several
 
Per the PTO trademark application instructions there may be several
 
benefits in obtaining a trademark.
 
benefits in obtaining a trademark.
 +
 
o  The filing date of the application is a constructive date of
 
o  The filing date of the application is a constructive date of
 
   first use of the mark in commerce (this gives registrant
 
   first use of the mark in commerce (this gives registrant
 
   nationwide priority as of the date).
 
   nationwide priority as of the date).
 +
 
o  The right to sue in Federal court for trademark infringement.
 
o  The right to sue in Federal court for trademark infringement.
 +
 
o  Constructive notice of claim of ownership.
 
o  Constructive notice of claim of ownership.
 +
 
o  Limited grounds for attacking a registration once it is five
 
o  Limited grounds for attacking a registration once it is five
 
   years old.
 
   years old.
−
=== How to Apply for a Trademark with the PTO ===
+
 
 +
=== How to Apply for a Trademark with the PTO ===
 +
 
 
You should obtain a trademark application and detailed instructions
 
You should obtain a trademark application and detailed instructions
 
from the U.S. Department of Commerce, Patent and Trademark Office.
 
from the U.S. Department of Commerce, Patent and Trademark Office.
 
This can be done by mailing your request to the address below, or
 
This can be done by mailing your request to the address below, or
 
calling the PTO at the phone number below:
 
calling the PTO at the phone number below:
 +
 
                     U.S. Department of Commerce
 
                     U.S. Department of Commerce
 
                     Patent and Trademark Office
 
                     Patent and Trademark Office
 
                     Washington, D.C.  20231
 
                     Washington, D.C.  20231
 
                     Phone:  (703) 557-INFO
 
                     Phone:  (703) 557-INFO
 +
 
NOTE:  The following information is based on ESnet experience in
 
NOTE:  The following information is based on ESnet experience in
 
       filing for a trademark based on prior use.
 
       filing for a trademark based on prior use.
 +
 
After you receive your application, you will need to perform the
 
After you receive your application, you will need to perform the
 
following steps.
 
following steps.
 +
 
1.  Complete the written application form.  If you have more than
 
1.  Complete the written application form.  If you have more than
−
 
−
 
−
 
−
 
−
 
−
 
  
 
     one name you are filing, you must complete a separate form for
 
     one name you are filing, you must complete a separate form for
 
     each name.
 
     each name.
 +
 
2.  Provide a black-and-white drawing of the mark.  In the case
 
2.  Provide a black-and-white drawing of the mark.  In the case
 
     where there is no artwork, only text, the text must be
 
     where there is no artwork, only text, the text must be
 
     centered on the page in uppercase.
 
     centered on the page in uppercase.
 +
 
3.  Provide a check in the amount of $175 (for each application)
 
3.  Provide a check in the amount of $175 (for each application)
 
     made payable to the Commissioner of Patents and Trademarks.
 
     made payable to the Commissioner of Patents and Trademarks.
 +
 
4.  Provide three specimens showing actual use of the mark on or
 
4.  Provide three specimens showing actual use of the mark on or
 
     in connection with the goods or services.
 
     in connection with the goods or services.
 +
 
The class of goods/services associated with this trademark must be
 
The class of goods/services associated with this trademark must be
 
specified on the registration form.  The currently defined classes of
 
specified on the registration form.  The currently defined classes of
 
services are:
 
services are:
 +
 
                   35  Advertising and business.
 
                   35  Advertising and business.
 
                   36  Insurance and financial.
 
                   36  Insurance and financial.
Line 1,759: Line 1,771:
 
                   41  Education and entertainment.
 
                   41  Education and entertainment.
 
                   42  Miscellaneous.
 
                   42  Miscellaneous.
 +
 
So, for example, there could be two (or more) "ESnet" trademarks,
 
So, for example, there could be two (or more) "ESnet" trademarks,
 
with each trademark associated with a different service class.  Thus,
 
with each trademark associated with a different service class.  Thus,
 
trademarks are not nationally unique.
 
trademarks are not nationally unique.
 +
 
Before submitting your form, you should see if your trademark is
 
Before submitting your form, you should see if your trademark is
 
already registered to someone else (for the service class you
 
already registered to someone else (for the service class you
 
specified).  This is typically done by your legal department through
 
specified).  This is typically done by your legal department through
 
the PTO Trademark Search Library.
 
the PTO Trademark Search Library.
 +
 
Since the PTO form is a legal document, you must involve your legal
 
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
 
department and the documents may only be signed by someone who is a
Line 1,773: Line 1,788:
 
recognized representative was Dr. John Nuckolls, the director of the
 
recognized representative was Dr. John Nuckolls, the director of the
 
Lawrence Livermore National Laboratory.
 
Lawrence Livermore National Laboratory.
−
===  Future Name Registration Issues to be Considered ===
 
−
====  ANSI Registered ADMD and PRMD Names ====
 
−
There are discussions in the ANSI and CCITT communities revolving
 
−
 
−
 
−
 
  
 +
=== Future Name Registration Issues to be Considered ===
  
 +
==== 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
 
around the idea of having a formal registration of all ADMD and PRMD
Line 1,789: Line 1,801:
 
discussion phase now, but it may impact the cost of ANSI ADMD and
 
discussion phase now, but it may impact the cost of ANSI ADMD and
 
PRMD Name registration in the near future.
 
PRMD Name registration in the near future.
 +
 
Glossary
 
Glossary
 +
 
AA - See ADMINISTRATIVE AUTHORITY.
 
AA - See ADMINISTRATIVE AUTHORITY.
 +
 
ADDMD - See ADMINISTRATIVE DIRECTORY MANAGEMENT DOMAIN.
 
ADDMD - See ADMINISTRATIVE DIRECTORY MANAGEMENT DOMAIN.
 +
 
ADMD - See ADMINISTRATION MANAGEMENT DOMAIN.
 
ADMD - See ADMINISTRATION MANAGEMENT DOMAIN.
 +
 
ADMINISTRATION - An Administration denotes a public telecommunications
 
ADMINISTRATION - An Administration denotes a public telecommunications
 
   administration or other organization offering public
 
   administration or other organization offering public
 
   telecommunications services.
 
   telecommunications services.
 +
 
ADMINISTRATION MANAGEMENT DOMAIN - An Administrative Management Domain
 
ADMINISTRATION MANAGEMENT DOMAIN - An Administrative Management Domain
 
   (ADMD) is a management domain managed by an Administration;
 
   (ADMD) is a management domain managed by an Administration;
 
   generally one of the common carriers (e.g. AT&T, MCI, U.S. Sprint,
 
   generally one of the common carriers (e.g. AT&T, MCI, U.S. Sprint,
 
   etc.).
 
   etc.).
 +
 
ADMINISTRATIVE AUTHORITY - An entity which has administrative control
 
ADMINISTRATIVE AUTHORITY - An entity which has administrative control
 
   over all entries stored within a single Directory System Agent
 
   over all entries stored within a single Directory System Agent
 
   (DSA).
 
   (DSA).
 +
 
ADMINISTRATIVE DIRECTORY MANAGEMENT DOMAIN - An Administrative Directory
 
ADMINISTRATIVE DIRECTORY MANAGEMENT DOMAIN - An Administrative Directory
 
   Management Domain (ADDMD) is a Directory Management Domain (DMD)
 
   Management Domain (ADDMD) is a Directory Management Domain (DMD)
 
   which is managed by an administration.
 
   which is managed by an administration.
 +
 
AE - See APPLICATION ENTITY.
 
AE - See APPLICATION ENTITY.
 +
 
ALIAS - An entry of the class "alias" containing information used to
 
ALIAS - An entry of the class "alias" containing information used to
 
   provide an alternative name for an object.
 
   provide an alternative name for an object.
 +
 
ANSI - The American National Standards Institute.  ANSI is the official
 
ANSI - The American National Standards Institute.  ANSI is the official
 
   representative of the United States to ISO.
 
   representative of the United States to ISO.
 +
 
AP - See APPLICATION PROCESS.
 
AP - See APPLICATION PROCESS.
 +
 
APPLICATION ENTITY - An application entity is the OSI portion of an
 
APPLICATION ENTITY - An application entity is the OSI portion of an
 
   Application Process (AP).
 
   Application Process (AP).
 +
 
APPLICATION LAYER - The application layer is the portion of an OSI
 
APPLICATION LAYER - The application layer is the portion of an OSI
 
   system ultimately responsible for managing communication between
 
   system ultimately responsible for managing communication between
 
   application processes (APs).
 
   application processes (APs).
  
 +
APPLICATION PROCESS - An application process is an object executing in a
 +
  real system (computer).
  
−
 
−
 
−
 
−
 
−
 
−
APPLICATION PROCESS - An application process is an object executing in a
 
−
  real system (computer).
 
 
APPLICATION SERVICE ELEMENT - An application service element (ASE) is
 
APPLICATION SERVICE ELEMENT - An application service element (ASE) is
 
   the building block of an application entity (AE).  Each AE consists
 
   the building block of an application entity (AE).  Each AE consists
 
   of one or more service elements, as defined by its application
 
   of one or more service elements, as defined by its application
 
   context.
 
   context.
 +
 
ASE - See APPLICATION SERVICE ELEMENT.
 
ASE - See APPLICATION SERVICE ELEMENT.
 +
 
ATTRIBUTE - An attribute is the information of a particular type
 
ATTRIBUTE - An attribute is the information of a particular type
 
   concerning an object and appearing in an entry describing that
 
   concerning an object and appearing in an entry describing that
 
   object in the Directory Information base (DIB).
 
   object in the Directory Information base (DIB).
 +
 
ATTRIBUTE TYPE - An attribute type is that component of an attribute
 
ATTRIBUTE TYPE - An attribute type is that component of an attribute
 
   which indicates the class of information given by that attribute.
 
   which indicates the class of information given by that attribute.
 +
 
ATTRIBUTE VALUE - An attribute value is a particular instance of the
 
ATTRIBUTE VALUE - An attribute value is a particular instance of the
 
   class of information indicated by an attribute type.
 
   class of information indicated by an attribute type.
 +
 
BASE ATTRIBUTE SET - A minimum set of attributes whose values
 
BASE ATTRIBUTE SET - A minimum set of attributes whose values
 
   unambiguously identify a particular management domain.
 
   unambiguously identify a particular management domain.
 +
 
BODY - The body of the IP-message is the information the user wishes to
 
BODY - The body of the IP-message is the information the user wishes to
 
   communicate.
 
   communicate.
 +
 
CCITT - An international standards making organization specializing in
 
CCITT - An international standards making organization specializing in
 
   international communications standards and chartered by the United
 
   international communications standards and chartered by the United
 
   Nations.  "CCITT" is a french acronym meaning the International
 
   Nations.  "CCITT" is a french acronym meaning the International
 
   Telephone and Telegraph Consultative Committee.
 
   Telephone and Telegraph Consultative Committee.
 +
 
CHAINING - Chaining is a mode of interaction optionally used by a
 
CHAINING - Chaining is a mode of interaction optionally used by a
 
   Directory System Agent (DSA) which cannot perform an operation
 
   Directory System Agent (DSA) which cannot perform an operation
 
   itself.  The DSA chains by invoking the operation of another DSA
 
   itself.  The DSA chains by invoking the operation of another DSA
 
   and then relaying the outcome to the original requestor.
 
   and then relaying the outcome to the original requestor.
 +
 
CLNP - The OSI Connectionless Network Protocol.  CLNP's use is required
 
CLNP - The OSI Connectionless Network Protocol.  CLNP's use is required
 
   by GOSIP.
 
   by GOSIP.
 +
 
CONTENT - The piece of information that the originating User Agent (UA)
 
CONTENT - The piece of information that the originating User Agent (UA)
 
   wishes delivered to the recipient UA.  For inter-personal messaging
 
   wishes delivered to the recipient UA.  For inter-personal messaging
 
   (IPM) UAs, the content consists of either an IP message or an IPM-
 
   (IPM) UAs, the content consists of either an IP message or an IPM-
 
   status-report.
 
   status-report.
 +
 
COOPERATING USER AGENT - A User Agent (UA) that cooperates with another
 
COOPERATING USER AGENT - A User Agent (UA) that cooperates with another
 
   recipient's UA in order to facilitate the communication between
 
   recipient's UA in order to facilitate the communication between
 
   originator and recipient.
 
   originator and recipient.
  
 +
DAP - See DIRECTORY ACCESS PROTOCOL.
  
−
 
−
 
−
 
−
 
−
 
−
 
−
DAP - See DIRECTORY ACCESS PROTOCOL.
 
 
DELIVERY - The interaction by which the Message Transfer Agent (MTA)
 
DELIVERY - The interaction by which the Message Transfer Agent (MTA)
 
   transfers to a recipient User Agent (UA) the content of a message
 
   transfers to a recipient User Agent (UA) the content of a message
 
   plus the delivery envelope.
 
   plus the delivery envelope.
 +
 
DELIVERY ENVELOPE - The envelope which contains the information related
 
DELIVERY ENVELOPE - The envelope which contains the information related
 
   to the delivery of the message.
 
   to the delivery of the message.
 +
 
DESCRIPTIVE NAME - A name that denotes one and only one user in the
 
DESCRIPTIVE NAME - A name that denotes one and only one user in the
 
   Message Handling System (MHS).
 
   Message Handling System (MHS).
 +
 
DIB - See DIRECTORY INFORMATION BASE.
 
DIB - See DIRECTORY INFORMATION BASE.
 +
 
DIRECTORY - The Directory is a repository of information about objects
 
DIRECTORY - The Directory is a repository of information about objects
 
   and which provides directory services to its users which allow
 
   and which provides directory services to its users which allow
 
   access to the information.
 
   access to the information.
 +
 
DIRECTORY ACCESS PROTOCOL - The Directory Access Protocol (DAP) is the
 
DIRECTORY ACCESS PROTOCOL - The Directory Access Protocol (DAP) is the
 
   protocol used between a Directory user Agent (DUA) and a Directory
 
   protocol used between a Directory user Agent (DUA) and a Directory
 
   System Agent (DSA).
 
   System Agent (DSA).
 +
 
DIRECTORY ENTRY - A Directory Entry is a part of the Directory
 
DIRECTORY ENTRY - A Directory Entry is a part of the Directory
 
   Information Base (DIB) which contains information about an object.
 
   Information Base (DIB) which contains information about an object.
 +
 
DIRECTORY INFORMATION BASE - The Directory Information Base (DIB) is the
 
DIRECTORY INFORMATION BASE - The Directory Information Base (DIB) is the
 
   complete set of information to which the Directory provides access
 
   complete set of information to which the Directory provides access
 
   and which includes all pieces of information which can be read or
 
   and which includes all pieces of information which can be read or
 
   manipulated using the operations of the Directory.
 
   manipulated using the operations of the Directory.
 +
 
DIRECTORY INFORMATION TREE - The Directory Information Tree (DIT) is the
 
DIRECTORY INFORMATION TREE - The Directory Information Tree (DIT) is the
 
   Directory Information Base (DIB), considered as a tree, whose
 
   Directory Information Base (DIB), considered as a tree, whose
 
   vertices (other than the root) are the Directory entries.
 
   vertices (other than the root) are the Directory entries.
 +
 
DIRECTORY MANAGEMENT DOMAIN - A Directory Management Domain (DMD) is a
 
DIRECTORY MANAGEMENT DOMAIN - A Directory Management Domain (DMD) is a
 
   collection of one or more Directory System Agents (DSAs) and zero
 
   collection of one or more Directory System Agents (DSAs) and zero
 
   or more Directory User Agents (DUAs) which is managed by a single
 
   or more Directory User Agents (DUAs) which is managed by a single
 
   organization.
 
   organization.
 +
 
DIRECTORY SYSTEM AGENT - A Directory System Agent (DSA) is an OSI
 
DIRECTORY SYSTEM AGENT - A Directory System Agent (DSA) is an OSI
 
   application process which is part of the Directory.
 
   application process which is part of the Directory.
 +
 
DIRECTORY SYSTEM PROTOCOL - The Directory System Protocol (DSP) is the
 
DIRECTORY SYSTEM PROTOCOL - The Directory System Protocol (DSP) is the
 
   protocol used between two Directory System Agents (DSAs).
 
   protocol used between two Directory System Agents (DSAs).
 +
 
DIRECTORY USER - A Directory user is the entity or person that accesses
 
DIRECTORY USER - A Directory user is the entity or person that accesses
 
   the Directory.
 
   the Directory.
  
−
 
+
DIRECTORY USER AGENT - A Directory User Agent (DUA) is an OSI
−
 
 
−
 
 
−
 
 
−
 
 
−
 
 
−
 
 
−
DIRECTORY USER AGENT - A Directory User Agent (DUA) is an OSI
 
 
   application process which represents the user in accessing the
 
   application process which represents the user in accessing the
 
   Directory.
 
   Directory.
 +
 
DISTINGUISHED NAME - The distinguished name of a given object is the
 
DISTINGUISHED NAME - The distinguished name of a given object is the
 
   sequence of relative distinguished names (RDNs) of an entry which
 
   sequence of relative distinguished names (RDNs) of an entry which
 
   represents the object and those of all of its superior entries (in
 
   represents the object and those of all of its superior entries (in
 
   descending order).
 
   descending order).
 +
 
DIT - See DIRECTORY INFORMATION TREE.
 
DIT - See DIRECTORY INFORMATION TREE.
 +
 
DMD - See DIRECTORY MANAGEMENT DOMAIN.
 
DMD - See DIRECTORY MANAGEMENT DOMAIN.
 +
 
DN - See DISTINGUISHED NAME.
 
DN - See DISTINGUISHED NAME.
 +
 
DNS - See DOMAIN NAME SERVICE.
 
DNS - See DOMAIN NAME SERVICE.
 +
 
DOMAIN NAME SERVICE - A hierarchical, distributed naming service
 
DOMAIN NAME SERVICE - A hierarchical, distributed naming service
 
   currently used in the Internet.  DNS names typically take the form
 
   currently used in the Internet.  DNS names typically take the form
 
   of <machine.site.domain>, where <.domain> may be ".COM", ".EDU",
 
   of <machine.site.domain>, where <.domain> may be ".COM", ".EDU",
 
   ".GOV", ".MIL", ".NET", ".ORG" or ".<country-code>".
 
   ".GOV", ".MIL", ".NET", ".ORG" or ".<country-code>".
 +
 
DSA - See DIRECTORY SYSTEM AGENT.
 
DSA - See DIRECTORY SYSTEM AGENT.
 +
 
DSP - See DIRECTORY SYSTEM PROTOCOL.
 
DSP - See DIRECTORY SYSTEM PROTOCOL.
 +
 
DUA - See DIRECTORY USER AGENT.
 
DUA - See DIRECTORY USER AGENT.
 +
 
ENCODED INFORMATION TYPE - It is the code and format of information that
 
ENCODED INFORMATION TYPE - It is the code and format of information that
 
   appears in the body of an IP-message (examples of coded information
 
   appears in the body of an IP-message (examples of coded information
 
   types are Telex, TIFO (Group 4 Facsimile), and voice).
 
   types are Telex, TIFO (Group 4 Facsimile), and voice).
 +
 
ENVELOPE - A place in which the information to be used in the
 
ENVELOPE - A place in which the information to be used in the
 
   submission, delivery and relaying of a message is contained.
 
   submission, delivery and relaying of a message is contained.
 +
 
FIPS - Federal Information Processing Standard.  FIPS are produced by
 
FIPS - Federal Information Processing Standard.  FIPS are produced by
 
   NIST and specify a standard for the federal government, most FIPS
 
   NIST and specify a standard for the federal government, most FIPS
 
   reference other formal standards from ANSI, IEEE, ISO or CCITT.
 
   reference other formal standards from ANSI, IEEE, ISO or CCITT.
 +
 
GOSIP - The Government Open System Interconnection (OSI) Profile.  GOSIP
 
GOSIP - The Government Open System Interconnection (OSI) Profile.  GOSIP
 
   is a FIPS which defines the elements of OSI to be required by
 
   is a FIPS which defines the elements of OSI to be required by
 
   government purchasers and how those elements should be implemented.
 
   government purchasers and how those elements should be implemented.
 
   GOSIP is based on OSI standards and OIW implementor's agreements.
 
   GOSIP is based on OSI standards and OIW implementor's agreements.
 +
 
HEADING - The heading of an IP-message is the control information that
 
HEADING - The heading of an IP-message is the control information that
 
   characterizes an IP-message.
 
   characterizes an IP-message.
 +
 
INTERPERSONAL MESSAGING - Interpersonal Messaging (IPM) is communication
 
INTERPERSONAL MESSAGING - Interpersonal Messaging (IPM) is communication
  
 +
  between persons by exchanging messages.
  
−
 
−
 
−
 
−
 
−
 
−
  between persons by exchanging messages.
 
 
INTERPERSONAL MESSAGING SERVICE - The set of service elements which
 
INTERPERSONAL MESSAGING SERVICE - The set of service elements which
 
   enable users to exchange interpersonal messages.
 
   enable users to exchange interpersonal messages.
 +
 
INTERPERSONAL MESSAGING SYSTEM - An Interpersonal Messaging System
 
INTERPERSONAL MESSAGING SYSTEM - An Interpersonal Messaging System
 
   (IPMS) is the collection of User Agents (UAs) and Message Transfer
 
   (IPMS) is the collection of User Agents (UAs) and Message Transfer
 
   Agents (MTAs), which provide the Interpersonal Messaging Service.
 
   Agents (MTAs), which provide the Interpersonal Messaging Service.
 +
 
IP - A non-OSI network protocol, the Internet Protocol, used extensively
 
IP - A non-OSI network protocol, the Internet Protocol, used extensively
 
   in the Internet.  CLNP is the OSI alternative to IP.
 
   in the Internet.  CLNP is the OSI alternative to IP.
 +
 
IP-MESSAGE - An IP-message carries information generated by and
 
IP-MESSAGE - An IP-message carries information generated by and
 
   transferred between Interpersonal Messaging (IPM) User Agents
 
   transferred between Interpersonal Messaging (IPM) User Agents
 
   (UAs).  An IP-message contains a Heading and a Body.
 
   (UAs).  An IP-message contains a Heading and a Body.
 +
 
IPM - See INTERPERSONAL MESSAGING.
 
IPM - See INTERPERSONAL MESSAGING.
 +
 
IPM-STATUS-REPORT - The pieces of information generated by an
 
IPM-STATUS-REPORT - The pieces of information generated by an
 
   Interpersonal Messaging (IPM) User Agent Entity (UAE) and
 
   Interpersonal Messaging (IPM) User Agent Entity (UAE) and
 
   transferred to another IPM UAE, either to be used by that UAE or to
 
   transferred to another IPM UAE, either to be used by that UAE or to
 
   be conveyed to the user.
 
   be conveyed to the user.
 +
 
IPMS - See INTERPERSONAL MESSAGING SYSTEM.
 
IPMS - See INTERPERSONAL MESSAGING SYSTEM.
 +
 
ISO - An international standards making organization which, among other
 
ISO - An international standards making organization which, among other
 
   things, develops OSI standards.
 
   things, develops OSI standards.
 +
 
MANAGEMENT DOMAIN - The set of Message Handling System (MHS) entities
 
MANAGEMENT DOMAIN - The set of Message Handling System (MHS) entities
 
   managed by an Administration or organization that includes at least
 
   managed by an Administration or organization that includes at least
 
   one Message Transfer Agent (MTA).
 
   one Message Transfer Agent (MTA).
 +
 
MD - See MANAGEMENT DOMAIN.
 
MD - See MANAGEMENT DOMAIN.
 +
 
MESSAGE - In the context of Message Handling Systems (MHSs), the unit of
 
MESSAGE - In the context of Message Handling Systems (MHSs), the unit of
 
   information transferred by the Message Transfer System (MTS).  It
 
   information transferred by the Message Transfer System (MTS).  It
 
   consists of an envelope and a content.
 
   consists of an envelope and a content.
 +
 
MESSAGE HANDLING ADDRESS - An Originator/Recipient (O/R) address which
 
MESSAGE HANDLING ADDRESS - An Originator/Recipient (O/R) address which
 
   is comprised of an Administrative Management Domain (ADMD), a
 
   is comprised of an Administrative Management Domain (ADMD), a
 
   country name, and a set of user attributes.
 
   country name, and a set of user attributes.
 +
 
MESSAGE HANDLING SYSTEM - The set of User Agents (UAs) plus the Message
 
MESSAGE HANDLING SYSTEM - The set of User Agents (UAs) plus the Message
 
   Transfer System (MTS).
 
   Transfer System (MTS).
 +
 
MESSAGE TRANSFER AGENT - The functional component that, together with
 
MESSAGE TRANSFER AGENT - The functional component that, together with
 
   the other Message Transfer Agents (MTAs), constitutes the Message
 
   the other Message Transfer Agents (MTAs), constitutes the Message
 
   Transfer System (MTS).  The MTAs provide message transfer service
 
   Transfer System (MTS).  The MTAs provide message transfer service
−
 
−
 
−
 
−
 
−
 
−
 
  
 
   elements by:  (1) interacting with originating User Agents (UAs)
 
   elements by:  (1) interacting with originating User Agents (UAs)
Line 1,994: Line 2,042:
 
   based upon recipient designations, and (3) interacting with
 
   based upon recipient designations, and (3) interacting with
 
   recipient UAs via the delivery dialogue.
 
   recipient UAs via the delivery dialogue.
 +
 
MESSAGE TRANSFER AGENT ENTITY - The Message Transfer Agent Entity (MTAE)
 
MESSAGE TRANSFER AGENT ENTITY - The Message Transfer Agent Entity (MTAE)
 
   is an entity, located in an MTA, that is responsible for
 
   is an entity, located in an MTA, that is responsible for
 
   controlling the Message Transfer Layer (MTL).  It controls the
 
   controlling the Message Transfer Layer (MTL).  It controls the
 
   operation of the protocol to other peer entities in the MTL.
 
   operation of the protocol to other peer entities in the MTL.
 +
 
MESSAGE TRANSFER LAYER - The Message Transfer Layer (MTL) is a layer in
 
MESSAGE TRANSFER LAYER - The Message Transfer Layer (MTL) is a layer in
 
   the Application layer that provides Message Transfer System (MTS)
 
   the Application layer that provides Message Transfer System (MTS)
Line 2,004: Line 2,054:
 
   in the layer, namely the Message Transfer Agent Entities (MTAEs)
 
   in the layer, namely the Message Transfer Agent Entities (MTAEs)
 
   and the Submission and Delivery Entities (SDEs).
 
   and the Submission and Delivery Entities (SDEs).
 +
 
MESSAGE TRANSFER PROTOCOL - The Message Transfer Protocol (P1) is the
 
MESSAGE TRANSFER PROTOCOL - The Message Transfer Protocol (P1) is the
 
   protocol which defines the relaying of messages between Message
 
   protocol which defines the relaying of messages between Message
 
   Transfer Agents (MTAs) and other interactions necessary to provide
 
   Transfer Agents (MTAs) and other interactions necessary to provide
 
   Message Transfer layer (MTL) services.
 
   Message Transfer layer (MTL) services.
 +
 
MESSAGE TRANSFER SERVICE - The Message Transfer Service is the set of
 
MESSAGE TRANSFER SERVICE - The Message Transfer Service is the set of
 
   optional service elements provided by the Message Transfer System
 
   optional service elements provided by the Message Transfer System
 
   (MTS).
 
   (MTS).
 +
 
MESSAGE TRANSFER SYSTEM - The Message Transfer System (MTS) is the
 
MESSAGE TRANSFER SYSTEM - The Message Transfer System (MTS) is the
 
   collection of Message Transfer Agents (MTAs), which provide the
 
   collection of Message Transfer Agents (MTAs), which provide the
 
   Message Transfer Service elements.
 
   Message Transfer Service elements.
 +
 
MHS - See MESSAGE HANDLING SYSTEM.
 
MHS - See MESSAGE HANDLING SYSTEM.
 +
 
MTA - See MESSAGE TRANSFER AGENT.
 
MTA - See MESSAGE TRANSFER AGENT.
 +
 
MTAE - See MESSAGE TRANSFER AGENT ENTITY.
 
MTAE - See MESSAGE TRANSFER AGENT ENTITY.
 +
 
MTL - See MESSAGE TRANSFER LAYER.
 
MTL - See MESSAGE TRANSFER LAYER.
 +
 
MTS - See MESSAGE TRANSFER SYSTEM.
 
MTS - See MESSAGE TRANSFER SYSTEM.
 +
 
MULTICASTING - Multicasting is a mode of interaction which may
 
MULTICASTING - Multicasting is a mode of interaction which may
 
   optionally be used by a Directory System Agent (DSA) which cannot
 
   optionally be used by a Directory System Agent (DSA) which cannot
Line 2,025: Line 2,084:
 
   in parallel) and passes an appropriate outcome to the original
 
   in parallel) and passes an appropriate outcome to the original
 
   requestor).
 
   requestor).
 +
 
NAME - A name is a construct that singles out a particular object from
 
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
 
   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
 
   one object); however, it need not be unique (i.e. be the only name
 
   which unambiguously denotes the object).
 
   which unambiguously denotes the object).
 +
 
NIST - The national institute of standards, a government organization
 
NIST - The national institute of standards, a government organization
 
   which develops, endorses, and promulgates standards for use by the
 
   which develops, endorses, and promulgates standards for use by the
 
   U.S.  government.
 
   U.S.  government.
 +
 
O/R ADDRESS - See ORIGINATOR/RECIPIENT ADDRESS.
 
O/R ADDRESS - See ORIGINATOR/RECIPIENT ADDRESS.
 +
 
O/R NAME - See ORIGINATOR/RECIPIENT NAME.
 
O/R NAME - See ORIGINATOR/RECIPIENT NAME.
 +
 
OBJECT (OF INTEREST) - Anything in some "world", generally the world of
 
OBJECT (OF INTEREST) - Anything in some "world", generally the world of
 
   telecommunications and information processing or some part thereof,
 
   telecommunications and information processing or some part thereof,
Line 2,046: Line 2,104:
 
   interest to hold information on in the Directory Information Base
 
   interest to hold information on in the Directory Information Base
 
   (DIB).
 
   (DIB).
 +
 
OIW - The OSI Implementors workshop.  OIW is one of three regional
 
OIW - The OSI Implementors workshop.  OIW is one of three regional
 
   workshops (OIW, EWOS, AOW), which specifies implementation
 
   workshops (OIW, EWOS, AOW), which specifies implementation
Line 2,051: Line 2,110:
 
   from the Americas and the OIW is jointly sponsored by the IEEE
 
   from the Americas and the OIW is jointly sponsored by the IEEE
 
   (Institute of Electrical and Electronic Engineers) and NIST.
 
   (Institute of Electrical and Electronic Engineers) and NIST.
 +
 
OPEN SYSTEMS INTERCONNECTION - A term referring to the capability of
 
OPEN SYSTEMS INTERCONNECTION - A term referring to the capability of
 
   interconnecting different systems.
 
   interconnecting different systems.
 +
 
ORIGINATING USER AGENT - The Originating User Agent (UA) is a UA that
 
ORIGINATING USER AGENT - The Originating User Agent (UA) is a UA that
 
   submits to the Message Transfer System (MTS) a message to be
 
   submits to the Message Transfer System (MTS) a message to be
 
   transferred.
 
   transferred.
 +
 
ORIGINATOR - A user, a human being or computer process, from whom the
 
ORIGINATOR - A user, a human being or computer process, from whom the
 
   Message Handling System (MHS) accepts a message.
 
   Message Handling System (MHS) accepts a message.
 +
 
ORIGINATOR/RECIPIENT ADDRESS - A descriptive name for a User Agent (UA)
 
ORIGINATOR/RECIPIENT ADDRESS - A descriptive name for a User Agent (UA)
 
   that contains certain characteristics which help the Message
 
   that contains certain characteristics which help the Message
 
   Transfer System (MTS) to locate the UA's point of attachment.  An
 
   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 (O/R) address is a type of O/R name.
 +
 
ORIGINATOR/RECIPIENT NAME - The Originator/Recipient Name (O/R Name) is
 
ORIGINATOR/RECIPIENT NAME - The Originator/Recipient Name (O/R Name) is
 
   the descriptive name for a User Agent (UA).
 
   the descriptive name for a User Agent (UA).
 +
 
OSI - See OPEN SYSTEMS INTERCONNECTION.
 
OSI - See OPEN SYSTEMS INTERCONNECTION.
 +
 
PRDMD - See PRIVATE DIRECTORY MANAGEMENT DOMAIN.
 
PRDMD - See PRIVATE DIRECTORY MANAGEMENT DOMAIN.
 +
 
PRIMITIVE NAME - A name assigned by a naming authority.  Primitive names
 
PRIMITIVE NAME - A name assigned by a naming authority.  Primitive names
 
   are components of descriptive 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 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
 
PRIVATE MANAGEMENT DOMAIN - A Private Management Domain (PRMD) is a
 
   management domain managed by a company or non-commercial
 
   management domain managed by a company or non-commercial
 
   organization.
 
   organization.
 +
 
PRMD - See PRIVATE MANAGEMENT DOMAIN.
 
PRMD - See PRIVATE MANAGEMENT DOMAIN.
 +
 
RDN - See RELATIVE DISTINGUISHED NAME.
 
RDN - See RELATIVE DISTINGUISHED NAME.
 +
 
RECIPIENT - A user, a human being or computer process, who receives a
 
RECIPIENT - A user, a human being or computer process, who receives a
 
   message from the Message Handling System (MHS).
 
   message from the Message Handling System (MHS).
 +
 
RECIPIENT USER AGENT - A User Agent (UA) to which a message is delivered
 
RECIPIENT USER AGENT - A User Agent (UA) to which a message is delivered
 
   or that is specified for delivery.
 
   or that is specified for delivery.
 +
 
REFERRAL - A referral is an outcome which can be returned by a Directory
 
REFERRAL - A referral is an outcome which can be returned by a Directory
 
   System Agent (DSA) which cannot perform an operation itself, and
 
   System Agent (DSA) which cannot perform an operation itself, and
 
   which identifies one or more other DSAs more able to perform the
 
   which identifies one or more other DSAs more able to perform the
 
   operation.
 
   operation.
 +
 
RELATIVE DISTINGUISHED NAME - A Relative Distinguished Name (RDN) is a
 
RELATIVE DISTINGUISHED NAME - A Relative Distinguished Name (RDN) is a
 
   set of attribute value assertions, each of which is true,
 
   set of attribute value assertions, each of which is true,
 
   concerning the distinguished values of a particular entry.
 
   concerning the distinguished values of a particular entry.
 +
 
RELAYING - The interaction by which one Message Transfer Agent (MTA)
 
RELAYING - The interaction by which one Message Transfer Agent (MTA)
 
   transfers to another MTA the content of a message plus the relaying
 
   transfers to another MTA the content of a message plus the relaying
 
   envelope.
 
   envelope.
 +
 
RELAYING ENVELOPE - The envelope which contains the information related
 
RELAYING ENVELOPE - The envelope which contains the information related
 
   to the operation of the Message Transfer System (MTS) plus the
 
   to the operation of the Message Transfer System (MTS) plus the
 
   service elements requested by the originating User Agent (UA).
 
   service elements requested by the originating User Agent (UA).
 +
 
RFC - Request for Comments.  The RFC's are documents used to propose or
 
RFC - Request for Comments.  The RFC's are documents used to propose or
 
   specify internet community standards.
 
   specify internet community standards.
 +
 
ROOT - The vertex that is not the final vertex of any arc is referred to
 
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.
 
   as the root vertex (or informally as the root) of the tree.
 +
 
SCHEMA - The Directory Schema is the set of rules and constraints
 
SCHEMA - The Directory Schema is the set of rules and constraints
 
   concerning the Directory Information Tree (DIT) structure, object
 
   concerning the Directory Information Tree (DIT) structure, object
 
   class definitions, attribute types, and syntaxes which characterize
 
   class definitions, attribute types, and syntaxes which characterize
 
   the Directory Information base (DIB).
 
   the Directory Information base (DIB).
 +
 
SDE - See SUBMISSION AND DELIVERY ENTITY.
 
SDE - See SUBMISSION AND DELIVERY ENTITY.
−
 
−
 
−
 
−
 
−
 
−
 
−
 
  
 
SMTP - Simple Mail Transfer Protocol.  An e-mail protocol frequently
 
SMTP - Simple Mail Transfer Protocol.  An e-mail protocol frequently
 
   used by the Internet community.
 
   used by the Internet community.
 +
 
SUBMISSION - The interaction by which an originating User Agent (UA)
 
SUBMISSION - The interaction by which an originating User Agent (UA)
 
   transfers to a Message Transfer Agent (MTA) the contents of a
 
   transfers to a Message Transfer Agent (MTA) the contents of a
 
   message plus the submission envelope.
 
   message plus the submission envelope.
 +
 
SUBMISSION AND DELIVERY ENTITY - The Submission and Delivery Entity
 
SUBMISSION AND DELIVERY ENTITY - The Submission and Delivery Entity
 
   (SDE) is an entity located in the Message Transfer Layer (MTL),
 
   (SDE) is an entity located in the Message Transfer Layer (MTL),
Line 2,127: Line 2,196:
 
   Agent (MTA), and responsible for controlling the submission and
 
   Agent (MTA), and responsible for controlling the submission and
 
   delivery interactions with a Message Transfer Agent Entity (MTAE).
 
   delivery interactions with a Message Transfer Agent Entity (MTAE).
 +
 
SUBMISSION AND DELIVERY PROTOCOL - The Submission and Delivery Protocol
 
SUBMISSION AND DELIVERY PROTOCOL - The Submission and Delivery Protocol
 
   (P3) is the protocol which governs communication between a
 
   (P3) is the protocol which governs communication between a
 
   Submission and Delivery Entity (SDE) and a Message Transfer Agent
 
   Submission and Delivery Entity (SDE) and a Message Transfer Agent
 
   Entity (MTAE).
 
   Entity (MTAE).
 +
 
SUBMISSION ENVELOPE - The envelope which contains the information the
 
SUBMISSION ENVELOPE - The envelope which contains the information the
 
   Message Transfer System (MTS) requires to provide the requested
 
   Message Transfer System (MTS) requires to provide the requested
 
   service elements.
 
   service elements.
 +
 
TCP - A non-OSI transport protocol, the Transmission Control Protocol,
 
TCP - A non-OSI transport protocol, the Transmission Control Protocol,
 
   used extensively in the Internet.  TP4 is the OSI alternative to
 
   used extensively in the Internet.  TP4 is the OSI alternative to
 
   TCP.
 
   TCP.
 +
 
TP0 - An OSI transport protocol specified by GOSIP and generally used
 
TP0 - An OSI transport protocol specified by GOSIP and generally used
 
   with connection-oriented networks.
 
   with connection-oriented networks.
 +
 
TP4 - An OSI transport protocol specified by GOSIP and generally used
 
TP4 - An OSI transport protocol specified by GOSIP and generally used
 
   with connectionless networks such as CLNP.
 
   with connectionless networks such as CLNP.
 +
 
TREE - A tree is a set of points (vertices), and a set of directed lines
 
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
 
   (arcs); each arc leads from a vertex V to a vertex V'.  The
Line 2,146: Line 2,221:
 
   an arc a from V to V'.  In a tree, several different arcs may have
 
   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.
 
   the same initial vertex, but not the same final vertex.
 +
 
UA - See USER AGENT.
 
UA - See USER AGENT.
 +
 
UAE - See USER AGENT ENTITY.
 
UAE - See USER AGENT ENTITY.
 +
 
UAL - See USER AGENT LAYER.
 
UAL - See USER AGENT LAYER.
 +
 
USER - A person or computer application or process who makes use of a
 
USER - A person or computer application or process who makes use of a
 
   Message Handling System (MHS).
 
   Message Handling System (MHS).
 +
 
USER AGENT - Typically, the User Agent (UA) is a set of computer
 
USER AGENT - Typically, the User Agent (UA) is a set of computer
  
−
 
+
   processes (for example, an editor, a file system, a word processor)
−
 
 
−
 
 
−
 
 
−
 
 
−
 
 
−
   processes (for example, an editor, a file system, a word processor)
 
 
   that are used to create, inspect, and manage the storage of
 
   that are used to create, inspect, and manage the storage of
 
   messages.  There is typically one user per User Agent (UA).  During
 
   messages.  There is typically one user per User Agent (UA).  During
Line 2,169: Line 2,243:
 
   messages, the UA interacts with the MTS via the submission and
 
   messages, the UA interacts with the MTS via the submission and
 
   delivery protocol.
 
   delivery protocol.
 +
 
USER AGENT ENTITY - A User Agent Entity (UAE) is an entity in the User
 
USER AGENT ENTITY - A User Agent Entity (UAE) is an entity in the User
 
   Agent Layer (UAL) of the Application Layer that controls the
 
   Agent Layer (UAL) of the Application Layer that controls the
Line 2,177: Line 2,252:
 
   layer (MTL) requires to create the appropriate envelope and thus
 
   layer (MTL) requires to create the appropriate envelope and thus
 
   provide the desired message transfer service elements.
 
   provide the desired message transfer service elements.
 +
 
USER AGENT LAYER - The User Agent Layer (UAL) is the layer that contains
 
USER AGENT LAYER - The User Agent Layer (UAL) is the layer that contains
 
   the User Agent Entities (UAEs).
 
   the User Agent Entities (UAEs).
 +
 
X.25 - A packet switched network standard often used by public providers
 
X.25 - A packet switched network standard often used by public providers
 
   and optional in GOSIP.
 
   and optional in GOSIP.
 +
 
Appendix A:  Current Activities in X.500
 
Appendix A:  Current Activities in X.500
 +
 
NOTE:  The following are edited excerpts from the IETF Directory
 
NOTE:  The following are edited excerpts from the IETF Directory
 
Services Monthly reports as well as a few IETF scope documents.
 
Services Monthly reports as well as a few IETF scope documents.
Line 2,187: Line 2,266:
 
late 1991.  At the end of each section are lists of anonymous FTP
 
late 1991.  At the end of each section are lists of anonymous FTP
 
and/or an e-mail address if more information is desired.
 
and/or an e-mail address if more information is desired.
 +
 
                               IETF DISI
 
                               IETF DISI
 
     (Directory Information Services Infrastructure Working Group)
 
     (Directory Information Services Infrastructure Working Group)
 +
 
The Directory Information Services (pilot) Infrastructure Working
 
The Directory Information Services (pilot) Infrastructure Working
 
Group is chartered to facilitate the deployment in the Internet of
 
Group is chartered to facilitate the deployment in the Internet of
Line 2,201: Line 2,282:
 
TCP/IP and CLNP, the DISI working group shall not mandate specific
 
TCP/IP and CLNP, the DISI working group shall not mandate specific
  
 +
implementations or transport protocols.
  
−
 
−
 
−
 
−
 
−
 
−
implementations or transport protocols.
 
 
DISI is an offshoot of the OSI Directory Services group, and,
 
DISI is an offshoot of the OSI Directory Services group, and,
 
accordingly, is a combined effort of the OSI Integration Area and
 
accordingly, is a combined effort of the OSI Integration Area and
Line 2,218: Line 2,294:
 
with an eye towards truly operational status, DISI will need to form
 
with an eye towards truly operational status, DISI will need to form
 
liaisons with COSINE, PARADISE, and perhaps the RARE WG3.
 
liaisons with COSINE, PARADISE, and perhaps the RARE WG3.
 +
 
As a final document, the DISI working group shall write a charter for
 
As a final document, the DISI working group shall write a charter for
 
a new working group concerned with user services, integration,
 
a new working group concerned with user services, integration,
 
maintenance and operations of Directory Services, the Operations and
 
maintenance and operations of Directory Services, the Operations and
 
Infrastructure of Directory Services (OIDS) Group.
 
Infrastructure of Directory Services (OIDS) Group.
 +
 
One particular DISI document you may be interested in is a catalogue
 
One particular DISI document you may be interested in is a catalogue
 
of the various X.500 implementations:
 
of the various X.500 implementations:
 +
 
   Title    : Catalog of Available X.500 Implementations
 
   Title    : Catalog of Available X.500 Implementations
 
   Author(s) : R. Lang, R. Wright
 
   Author(s) : R. Lang, R. Wright
 
   Filename  : rfc1292.txt
 
   Filename  : rfc1292.txt
 
   Pages    : 103
 
   Pages    : 103
 +
 
This document is available on the ESnet Information Server in the
 
This document is available on the ESnet Information Server in the
 
[ANONYMOUS.RFCS] directory.
 
[ANONYMOUS.RFCS] directory.
 +
 
Mailing list address:
 
Mailing list address:
 
   General Discussion:  [email protected]
 
   General Discussion:  [email protected]
Line 2,235: Line 2,316:
 
Anonymous FTP site address:  (e-mail archive is here)
 
Anonymous FTP site address:  (e-mail archive is here)
 
   merit.edu
 
   merit.edu
 +
 
           IETF OSI-DS (OSI Directory Service Working Group)
 
           IETF OSI-DS (OSI Directory Service Working Group)
 +
 
The OSI-DS group works on issues relating to building an OSI
 
The OSI-DS group works on issues relating to building an OSI
 
Directory Service using X.500 and its deployment on the Internet.
 
Directory Service using X.500 and its deployment on the Internet.
Line 2,241: Line 2,324:
 
is practical, and technical work needed as a pre-requisite to
 
is practical, and technical work needed as a pre-requisite to
 
deployment of an open Directory will be considered.
 
deployment of an open Directory will be considered.
 +
 
The major goal of this WG is to provide the technical framework for a
 
The major goal of this WG is to provide the technical framework for a
 
Directory Service infrastructure on the Internet.  This
 
Directory Service infrastructure on the Internet.  This
Line 2,246: Line 2,330:
 
intended that this infrastructure can be used by many applications.
 
intended that this infrastructure can be used by many applications.
 
Whilst this WG is not directly concerned with operation of services,
 
Whilst this WG is not directly concerned with operation of services,
−
 
−
 
−
 
−
 
−
 
−
 
  
 
close liaison is expected with those groups which do operate pilots
 
close liaison is expected with those groups which do operate pilots
 
and services.
 
and services.
 +
 
Liaisons have been established with RARE WG3, NIST, CCITT/ISO IEC,
 
Liaisons have been established with RARE WG3, NIST, CCITT/ISO IEC,
 
North American Directory Forum.
 
North American Directory Forum.
 +
 
X.500 (1984) / ISO 9594 does not have sufficient functionality for
 
X.500 (1984) / ISO 9594 does not have sufficient functionality for
 
full deployment on the Internet.  This group identifies areas where
 
full deployment on the Internet.  This group identifies areas where
 
extensions are required.
 
extensions are required.
 +
 
It is a basic aim of the group to be aligned to appropriate base
 
It is a basic aim of the group to be aligned to appropriate base
 
standards and functional standards.  Any activity should be
 
standards and functional standards.  Any activity should be
 
undertaken in the light of ongoing standardization activity.  Areas
 
undertaken in the light of ongoing standardization activity.  Areas
 
which should be examined include:
 
which should be examined include:
 +
 
o  Replication
 
o  Replication
 +
 
o  Knowledge Representation
 
o  Knowledge Representation
 +
 
o  Schema Management
 
o  Schema Management
 +
 
o  Access Control
 
o  Access Control
 +
 
o  Authentication
 
o  Authentication
 +
 
o  Distributed operations for partially connected DSAs
 
o  Distributed operations for partially connected DSAs
 +
 
o  Presentation Address Handling
 
o  Presentation Address Handling
 +
 
Mailing list address:
 
Mailing list address:
 
   General Discussion:  [email protected]
 
   General Discussion:  [email protected]
Line 2,276: Line 2,365:
 
Anonymous FTP site address:  (all OSI-DS documents and e-mail archive
 
Anonymous FTP site address:  (all OSI-DS documents and e-mail archive
 
   cs.ucl.ac.uk              are here)
 
   cs.ucl.ac.uk              are here)
 +
 
                 FOX (Field Operational X.500 Project)
 
                 FOX (Field Operational X.500 Project)
 +
 
The FOX project is a DARPA funded effort to provide a basis for
 
The FOX project is a DARPA funded effort to provide a basis for
 
operational X.500 deployment in the NREN/Internet.  This work is
 
operational X.500 deployment in the NREN/Internet.  This work is
 
being carried out at Merit, NYSERnet/PSI, SRI and ISI.  ISI is the
 
being carried out at Merit, NYSERnet/PSI, SRI and ISI.  ISI is the
 
main contractor and responsible for project oversight.
 
main contractor and responsible for project oversight.
 +
 
There are two primary thrusts of the FOX project:
 
There are two primary thrusts of the FOX project:
 +
 
1.  X.500 Infrastructure:  It is important that multiple
 
1.  X.500 Infrastructure:  It is important that multiple
 
     interoperable platforms be available for deployment.  FOX
 
     interoperable platforms be available for deployment.  FOX
 
     plans to examine and test the interoperability of the QUIPU
 
     plans to examine and test the interoperability of the QUIPU
 
     and NIST-X.500 (Custos) implementations, and DNANS-X.500 if
 
     and NIST-X.500 (Custos) implementations, and DNANS-X.500 if
−
 
−
 
−
 
−
 
−
 
−
 
  
 
     possible.  In addition, FOX will explore X.500 interfaces to
 
     possible.  In addition, FOX will explore X.500 interfaces to
Line 2,297: Line 2,384:
 
     alternate OS platform (VM) for X.500 servers, and X-window
 
     alternate OS platform (VM) for X.500 servers, and X-window
 
     based user interfaces.
 
     based user interfaces.
 +
 
2.  X.500 Applications:  A long-range goal is to facilitate the
 
2.  X.500 Applications:  A long-range goal is to facilitate the
 
     use of X.500 for real Internet applications.  FOX will first
 
     use of X.500 for real Internet applications.  FOX will first
Line 2,302: Line 2,390:
 
     through X.500.  This includes network and AS site contacts,
 
     through X.500.  This includes network and AS site contacts,
 
     topology information, and the NIC WHOIS service.
 
     topology information, and the NIC WHOIS service.
 +
 
A centrally managed X.500 version will be the first phase of a WHOIS
 
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.  Providing an X.500 version of a well-known widely-used
Line 2,309: Line 2,398:
 
short-lived, so the next step will be a design for a distributed
 
short-lived, so the next step will be a design for a distributed
 
version of WHOIS.
 
version of WHOIS.
 +
 
Finally, it is critical for Internet X.500 efforts to be aligned with
 
Finally, it is critical for Internet X.500 efforts to be aligned with
 
directory service efforts that are ongoing in other communities.  FOX
 
directory service efforts that are ongoing in other communities.  FOX
Line 2,314: Line 2,404:
 
efforts, and information about FOX activities will be publicly
 
efforts, and information about FOX activities will be publicly
 
available.
 
available.
 +
 
                 NADF (North American Directory Forum)
 
                 NADF (North American Directory Forum)
 +
 
The North American Directory Forum (NADF) is a collection of
 
The North American Directory Forum (NADF) is a collection of
 
organizations which offer, or plan to offer, public Directory
 
organizations which offer, or plan to offer, public Directory
 
services in North America, based on the CCITT X.500 Recommendations.
 
services in North America, based on the CCITT X.500 Recommendations.
 +
 
The NADF has produced a document, NADF-175, "A Naming Scheme for
 
The NADF has produced a document, NADF-175, "A Naming Scheme for
 
c=US", which has been issued as RFC-1255.
 
c=US", which has been issued as RFC-1255.
 +
 
The NADF-175 document proposes the use of existing civil
 
The NADF-175 document proposes the use of existing civil
 
infrastructure for naming objects under c=US.  This has the advantage
 
infrastructure for naming objects under c=US.  This has the advantage
Line 2,328: Line 2,422:
 
term; it is important that interested parties get a copy, review it,
 
term; it is important that interested parties get a copy, review it,
 
and return comments.
 
and return comments.
 +
 
A second output, which is still undergoing development, is NADF-128,
 
A second output, which is still undergoing development, is NADF-128,
 
a preliminary draft on "Mapping the DIT onto Multiple ADDMDs".  This
 
a preliminary draft on "Mapping the DIT onto Multiple ADDMDs".  This
Line 2,334: Line 2,429:
 
working public directory.  The next revision of this document will
 
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)
  
−
 
−
 
−
 
−
 
−
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
 
NIST is involved in several X.500 activities:  standards, pilot
 
deployment, and development of an X.500 implementation, Custos.  The
 
deployment, and development of an X.500 implementation, Custos.  The
Line 2,349: Line 2,440:
 
is on access control and replication; the other activities are
 
is on access control and replication; the other activities are
 
described in some detail below.
 
described in some detail below.
 +
 
o  NIST/GSA X.500 Pilot Deployment:  NIST and GSA are
 
o  NIST/GSA X.500 Pilot Deployment:  NIST and GSA are
 
   collaborating in the creation of a U.S. Government X.500 pilot
 
   collaborating in the creation of a U.S. Government X.500 pilot
Line 2,360: Line 2,452:
 
   on Custos DSAs running at NIST.  Eventually, agencies are
 
   on Custos DSAs running at NIST.  Eventually, agencies are
 
   expected to obtain and operate DSAs.
 
   expected to obtain and operate DSAs.
 +
 
o  CUSTOS:  The NIST X.500 public-domain implementation, Custos,
 
o  CUSTOS:  The NIST X.500 public-domain implementation, Custos,
 
   is implemented on ISODE, although it otherwise bears no
 
   is implemented on ISODE, although it otherwise bears no
Line 2,367: Line 2,460:
 
   loaded into memory, and the memory usage is reasonably
 
   loaded into memory, and the memory usage is reasonably
 
   efficient on a per-entry basis.
 
   efficient on a per-entry basis.
 +
 
                   OIW (OSI Implementor's Workshop)
 
                   OIW (OSI Implementor's Workshop)
 +
 
The OSI Implementor's Workshop (OIW) is an open public forum for
 
The OSI Implementor's Workshop (OIW) is an open public forum for
 
technical issues, concerned with the timely development of
 
technical issues, concerned with the timely development of
Line 2,377: Line 2,472:
 
and to promote interoperability of independently manufactured data
 
and to promote interoperability of independently manufactured data
 
communications equipment.
 
communications equipment.
 +
 
The Workshop organizes its work through Special Interest Groups
 
The Workshop organizes its work through Special Interest Groups
 
(SIGs) that prepare technical documentation.  The SIGs are encouraged
 
(SIGs) that prepare technical documentation.  The SIGs are encouraged
Line 2,382: Line 2,478:
 
seek widespread technical consensus on implementation agreements
 
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
−
 
 
−
 
 
−
 
 
−
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
 
X.500 Recommendations.  There are three major areas that the SIG is
 
working on for 1991:  access control, replication, and distributed
 
working on for 1991:  access control, replication, and distributed
 
operations.
 
operations.
 +
 
Mailing list address:
 
Mailing list address:
 
   General Discussion:  [email protected]
 
   General Discussion:  [email protected]
 
   To Subscribe:        [email protected]
 
   To Subscribe:        [email protected]
 +
 
                           PARADISE Project
 
                           PARADISE Project
 +
 
The PARADISE project is based at the Department of Computer Science,
 
The PARADISE project is based at the Department of Computer Science,
 
University College London (UCL).
 
University College London (UCL).
 +
 
PARADISE is a sub-project of the broader COSINE project sponsored
 
PARADISE is a sub-project of the broader COSINE project sponsored
 
under the umbrella of EUREKA by eighteen participating countries and
 
under the umbrella of EUREKA by eighteen participating countries and
Line 2,408: Line 2,503:
 
Ireland, Italy, Luxembourg, Norway, Portugal, Spain, Sweden,
 
Ireland, Italy, Luxembourg, Norway, Portugal, Spain, Sweden,
 
Switzerland, United Kingdom, and Yugoslavia.
 
Switzerland, United Kingdom, and Yugoslavia.
 +
 
The partners funded by PARADISE besides UCL are:
 
The partners funded by PARADISE besides UCL are:
 +
 
o  The Networks Group at the University of London Computer Centre
 
o  The Networks Group at the University of London Computer Centre
 
   (ULCC), which is a service-oriented organization providing a
 
   (ULCC), which is a service-oriented organization providing a
Line 2,414: Line 2,511:
 
   entry point into the UK for IXI, the COSINE international X.25
 
   entry point into the UK for IXI, the COSINE international X.25
 
   backbone;
 
   backbone;
 +
 
o  X-Tel Services Ltd, a software company based in Nottingham
 
o  X-Tel Services Ltd, a software company based in Nottingham
 
   which currently provides service support to the UK Academic
 
   which currently provides service support to the UK Academic
 
   X.500 pilot; and
 
   X.500 pilot; and
 +
 
o  PTT Telematic Systems from the Netherlands, which in turn has
 
o  PTT Telematic Systems from the Netherlands, which in turn has
 
   subcontracted the Swiss and Finnish PTTs, and whose involvement
 
   subcontracted the Swiss and Finnish PTTs, and whose involvement
 
   is to create a forum for discussion on X.500 among the European
 
   is to create a forum for discussion on X.500 among the European
 
   carrier administrations.
 
   carrier administrations.
 +
 
The project also aims to have representation from all the
 
The project also aims to have representation from all the
 
participating countries, which in the majority of cases are the
 
participating countries, which in the majority of cases are the
 
existing X.500 national pilots.
 
existing X.500 national pilots.
 +
 
Of the 18 countries involved, at least 12 are registered in the White
 
Of the 18 countries involved, at least 12 are registered in the White
−
 
−
 
−
 
−
 
−
 
−
 
  
 
Pages Pilot Project.  Most countries are using the QUIPU
 
Pages Pilot Project.  Most countries are using the QUIPU
Line 2,438: Line 2,533:
 
DirWiz, which is currently the sole representative from Italy in the
 
DirWiz, which is currently the sole representative from Italy in the
 
tree.
 
tree.
 +
 
Mailing list address:
 
Mailing list address:
  
 +
 
                     PSI White Pages Pilot Project
 
                     PSI White Pages Pilot Project
 +
 
The White Pages Pilot Project is the first production-quality field
 
The White Pages Pilot Project is the first production-quality field
 
test of the OSI Directory (X.500).  The pilot currently has a few
 
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
 
hundred organizations (more each month) and is based on OSI TP4 over
 
TCP/IP (RFC-1006).
 
TCP/IP (RFC-1006).
 +
 
Anonymous FTP site address:  (Most X.500 pilot project software is
 
Anonymous FTP site address:  (Most X.500 pilot project software is
 
   uu.psi.com                here as well as more information)
 
   uu.psi.com                here as well as more information)
 +
 
               ANSI ASC X3T5.4 (Directory Ad Hoc Group)
 
               ANSI ASC X3T5.4 (Directory Ad Hoc Group)
 +
 
The American National Standards Institute (ANSI) Accredited Standards
 
The American National Standards Institute (ANSI) Accredited Standards
 
Committee (ASC) X3T5.4.  This group reviews the Proposed Draft
 
Committee (ASC) X3T5.4.  This group reviews the Proposed Draft
Line 2,454: Line 2,555:
 
Recommendations/International Organization for Standardization
 
Recommendations/International Organization for Standardization
 
(ISO)/International Electrotechnical Commission (IEC) 9594.
 
(ISO)/International Electrotechnical Commission (IEC) 9594.
 +
 
Appendix B:  Current Activities in X.400
 
Appendix B:  Current Activities in X.400
 +
 
NOTE:  The following are edited excerpts from the IETF X.400 Services
 
NOTE:  The following are edited excerpts from the IETF X.400 Services
 
Monthly reports as well as a few IETF scope documents.  Effort has
 
Monthly reports as well as a few IETF scope documents.  Effort has
Line 2,460: Line 2,563:
 
1992.  At the end of each section are lists of anonymous FTP and/or
 
1992.  At the end of each section are lists of anonymous FTP and/or
 
an e-mail address if more information is desired.
 
an e-mail address if more information is desired.
 +
 
             IETF OSIX400 (IETF OSI X.400 Working Group)
 
             IETF OSIX400 (IETF OSI X.400 Working Group)
 +
 
The IETF OSI X.400 Working Group is chartered to identify and provide
 
The IETF OSI X.400 Working Group is chartered to identify and provide
 
solutions for problems encountered when operating X.400 in a dual
 
solutions for problems encountered when operating X.400 in a dual
 
protocol internet.  This charter includes pure X.400 operational
 
protocol internet.  This charter includes pure X.400 operational
−
issues as well as X.400 <-> RFC 822 gateway (ala RFC 987) issues.
+
issues as well as X.400 <-> [[RFC822|RFC 822]] gateway (ala [[RFC987|RFC 987]]) issues.
 +
 
 
Mailing list address:
 
Mailing list address:
 
   General Discussion:  [email protected]
 
   General Discussion:  [email protected]
 
   To Subscribe:        [email protected]
 
   To Subscribe:        [email protected]
  
 +
        IETF X400OPS (IETF X.400 Operations Working Group)
  
−
 
−
 
−
 
−
 
−
 
−
 
−
        IETF X400OPS (IETF X.400 Operations Working Group)
 
 
X.400 management domains are being deployed today on the Internet.
 
X.400 management domains are being deployed today on the Internet.
 
There is a need for coordination of the various efforts to insure
 
There is a need for coordination of the various efforts to insure
Line 2,486: Line 2,586:
 
to produce a document that specifies the requirements and conventions
 
to produce a document that specifies the requirements and conventions
 
of operational Internet PRMDs.
 
of operational Internet PRMDs.
 +
 
Mailing list address:
 
Mailing list address:
 
   General Discussion:  [email protected]
 
   General Discussion:  [email protected]
 
   To Subscribe:        [email protected]
 
   To Subscribe:        [email protected]
 +
 
   IETF MHS-DS (IETF Message Handling Services - Directory Services)
 
   IETF MHS-DS (IETF Message Handling Services - Directory Services)
 +
 
The MHS-DS Group works on issues relating to Message Handling Service
 
The MHS-DS Group works on issues relating to Message Handling Service
 
use of Directory Services.  The Message Handling Services are
 
use of Directory Services.  The Message Handling Services are
−
primarily X.400, but issues relating to RFC 822 and RFC 822
+
primarily X.400, but issues relating to [[RFC822|RFC 822]] and [[RFC822|RFC 822]]
 
interworking, in as far as use of the Directory is concerned, are in
 
interworking, in as far as use of the Directory is concerned, are in
 
the scope of the Group.  Directory Services means the services based
 
the scope of the Group.  Directory Services means the services based
Line 2,501: Line 2,604:
 
is practical, and implementations of this work by members of the
 
is practical, and implementations of this work by members of the
 
Group is expected.
 
Group is expected.
 +
 
Mailing list address:
 
Mailing list address:
 
   General Discussion:  [email protected]
 
   General Discussion:  [email protected]
Line 2,506: Line 2,610:
 
Anonymous FTP site address:  (e-mail archive is here)
 
Anonymous FTP site address:  (e-mail archive is here)
 
   mercury.udev.cdc.com
 
   mercury.udev.cdc.com
 +
 
                       XNREN X.400 Pilot Project
 
                       XNREN X.400 Pilot Project
 +
 
The Internet X.400 Project at the University of Wisconsin is funded
 
The Internet X.400 Project at the University of Wisconsin is funded
 
by NSF.  We are working on two main areas:
 
by NSF.  We are working on two main areas:
 +
 
1.  Supporting the operational use of X.400.
 
1.  Supporting the operational use of X.400.
 +
 
2.  Working with others to define organizational procedures
 
2.  Working with others to define organizational procedures
 
     necessary to operate X.400 on a large scale in the Internet.
 
     necessary to operate X.400 on a large scale in the Internet.
 +
 
To support the use of X.400, we are operating a PRMD, assisting sites
 
To support the use of X.400, we are operating a PRMD, assisting sites
 
in running PP or the Wisconsin Argo X.400 software packages, and
 
in running PP or the Wisconsin Argo X.400 software packages, and
−
 
−
 
−
 
−
 
−
 
−
 
  
 
running an X.400 Message Transfer Agent (MTA) which is connected to
 
running an X.400 Message Transfer Agent (MTA) which is connected to
Line 2,526: Line 2,629:
 
organizational work is being done jointly by IETF working groups and
 
organizational work is being done jointly by IETF working groups and
 
RARE Working Group 1.
 
RARE Working Group 1.
 +
 
Mailing list address:
 
Mailing list address:
 
   General Discussion:  [email protected]
 
   General Discussion:  [email protected]
 +
 
     RARE WG1 (RARE Working Group 1 - Message Handling Systems)
 
     RARE WG1 (RARE Working Group 1 - Message Handling Systems)
 +
 
RARE (Reseaux Associes pour la Recherche Europeenne) Working Group 1,
 
RARE (Reseaux Associes pour la Recherche Europeenne) Working Group 1,
 
Message Handling Systems, creates and promotes a European
 
Message Handling Systems, creates and promotes a European
Line 2,535: Line 2,641:
 
Membership of the Working Group is by nomination from the national
 
Membership of the Working Group is by nomination from the national
 
networking organizations, together with a number of invited experts.
 
networking organizations, together with a number of invited experts.
 +
 
   CCITT SG-D MHS-MD (CCITT Study Group D, MHS Management Domains)
 
   CCITT SG-D MHS-MD (CCITT Study Group D, MHS Management Domains)
 +
 
This group initially pursues the  development of  the  rules for
 
This group initially pursues the  development of  the  rules for
 
registering MHS management Domain names within the US.  This group
 
registering MHS management Domain names within the US.  This group
Line 2,549: Line 2,657:
 
regardless of how many domains are involved in the transfer of the
 
regardless of how many domains are involved in the transfer of the
 
message  to the intended recipient.
 
message  to the intended recipient.
 +
 
The US State Department presently considers MHS  (e-mail)  as  an
 
The US State Department presently considers MHS  (e-mail)  as  an
 
Information  Processing  service.  Some other countries consider any
 
Information  Processing  service.  Some other countries consider any
 
MHS (e-mail) service  to  be  a Telecommunications  service  and
 
MHS (e-mail) service  to  be  a Telecommunications  service  and
 
hence, CCITT treaty obligations apply.
 
hence, CCITT treaty obligations apply.
 +
 
           NIST/GSA Interagency X.400 Connectivity Project
 
           NIST/GSA Interagency X.400 Connectivity Project
 +
 
The goal of this project is to assist the members of the Federal
 
The goal of this project is to assist the members of the Federal
 
Information Resource Management Policy Council (FIRMPoC) in
 
Information Resource Management Policy Council (FIRMPoC) in
Line 2,562: Line 2,673:
 
connectivity.  This project is sponsored by the General Services
 
connectivity.  This project is sponsored by the General Services
  
 +
Administration (GSA).
  
 +
Appendix C:  How to Obtain QUIPU, PP and ISODE
  
 +
                          ISODE/QUIPU 7.0
  
−
 
−
 
−
 
−
Administration (GSA).
 
−
Appendix C:  How to Obtain QUIPU, PP and ISODE
 
−
                          ISODE/QUIPU 7.0
 
 
This software supports the development of certain kinds of OSI
 
This software supports the development of certain kinds of OSI
 
protocols and applications.  Here are the details:
 
protocols and applications.  Here are the details:
 +
 
o  The ISODE is not proprietary, but it is not in the public
 
o  The ISODE is not proprietary, but it is not in the public
 
   domain.  This was necessary to include a "hold harmless"
 
   domain.  This was necessary to include a "hold harmless"
Line 2,579: Line 2,688:
 
   it, but no one takes any responsibility whatsoever for any
 
   it, but no one takes any responsibility whatsoever for any
 
   (mis)use.
 
   (mis)use.
 +
 
o  The ISODE runs on native Berkeley (4.2, 4.3) and AT&T System V
 
o  The ISODE runs on native Berkeley (4.2, 4.3) and AT&T System V
 
   systems, in addition to various other UNIX-like operating
 
   systems, in addition to various other UNIX-like operating
 
   systems.  No kernel modifications are required.
 
   systems.  No kernel modifications are required.
 +
 
o  Current modules include:
 
o  Current modules include:
 +
 
   -  OSI transport service (TP0 on top of TCP, X.25 and CONS;
 
   -  OSI transport service (TP0 on top of TCP, X.25 and CONS;
 
       TP4 for SunLink OSI)
 
       TP4 for SunLink OSI)
 +
 
   -  OSI session, presentation, and association control services
 
   -  OSI session, presentation, and association control services
 +
 
   -  ASN.1 abstract syntax/transfer notation tools, including:
 
   -  ASN.1 abstract syntax/transfer notation tools, including:
 +
 
       1.  Remote operations stub-generator (front-end for remote
 
       1.  Remote operations stub-generator (front-end for remote
 
           operations)
 
           operations)
 +
 
       2.  Structure-generator (ASN.1 to C)
 
       2.  Structure-generator (ASN.1 to C)
 +
 
       3.  Element-parser (basic encoding rules)
 
       3.  Element-parser (basic encoding rules)
 +
 
   -  OSI reliable transfer and remote operations services
 
   -  OSI reliable transfer and remote operations services
 +
 
   -  OSI directory services
 
   -  OSI directory services
 +
 
   -  OSI file transfer, access and management
 
   -  OSI file transfer, access and management
 +
 
   -  FTAM/FTP gateway
 
   -  FTAM/FTP gateway
 +
 
   -  OSI virtual terminal (basic class, TELNET profile)
 
   -  OSI virtual terminal (basic class, TELNET profile)
 +
 
o  ISODE 7.0 consists of final "IS" level implementations with the
 
o  ISODE 7.0 consists of final "IS" level implementations with the
 
   exception of VT which is a DIS implementation.  The ISODE also
 
   exception of VT which is a DIS implementation.  The ISODE also
−
 
−
 
−
 
−
 
−
 
−
 
  
 
   contains implementations of the 1984 X.400 versions of ROS and
 
   contains implementations of the 1984 X.400 versions of ROS and
 
   RTS.
 
   RTS.
 +
 
o  Although the ISODE is not "supported" per se, it does have a
 
o  Although the ISODE is not "supported" per se, it does have a
 
   problem reporting address, [email protected].  Bug reports
 
   problem reporting address, [email protected].  Bug reports
 
   (and fixes) are welcome by the way.
 
   (and fixes) are welcome by the way.
 +
 
o  The discussion group [email protected] is used as an open
 
o  The discussion group [email protected] is used as an open
 
   forum on ISODE.  Contact [email protected] to be added
 
   forum on ISODE.  Contact [email protected] to be added
 
   to this list.
 
   to this list.
 +
 
o  The primary documentation for this release consists of a five
 
o  The primary documentation for this release consists of a five
 
   volume User's Manual (approx. 1000 pages) and a set of UNIX
 
   volume User's Manual (approx. 1000 pages) and a set of UNIX
Line 2,621: Line 2,741:
 
   should probably get a hardcopy from one of the distribution
 
   should probably get a hardcopy from one of the distribution
 
   sites below.
 
   sites below.
 +
 
                   ISODE/QUIPU Distribution Sites
 
                   ISODE/QUIPU Distribution Sites
 +
 
The FTP or FTAM distributions of ISODE-7.0 consists of 3 files.  The
 
The FTP or FTAM distributions of ISODE-7.0 consists of 3 files.  The
 
source and main ISODE-7.0 distribution is in the file ISODE-7.tar.Z
 
source and main ISODE-7.0 distribution is in the file ISODE-7.tar.Z
 
which is approximately 4.7MB in size.
 
which is approximately 4.7MB in size.
 +
 
LaTeX source for the entire document set can be found in the ISODE-
 
LaTeX source for the entire document set can be found in the ISODE-
 
7-doc.tar.Z file (3.5MB).  A list of documents can be found in the
 
7-doc.tar.Z file (3.5MB).  A list of documents can be found in the
 
doc/ directory of the source tree.
 
doc/ directory of the source tree.
 +
 
A Postscript version of the five volume manual can be found in the
 
A Postscript version of the five volume manual can be found in the
 
ISODE-7-ps.tar.Z file (4.3MB).
 
ISODE-7-ps.tar.Z file (4.3MB).
 +
 
If you can FTP to the Internet, then use anonymous FTP to uu.psi.com
 
If you can FTP to the Internet, then use anonymous FTP to uu.psi.com
 
[136.161.128.3] to retrieve the files in BINARY mode from the ISODE/
 
[136.161.128.3] to retrieve the files in BINARY mode from the ISODE/
 
directory.
 
directory.
 +
 
               Additional PSI White Pages Pilot Software
 
               Additional PSI White Pages Pilot Software
 +
 
The 'usconfig' program configures a DSA which understands some of the
 
The 'usconfig' program configures a DSA which understands some of the
 
NADF naming rules.  This software is primarily intended for creating
 
NADF naming rules.  This software is primarily intended for creating
 
directory hierarchies for DSAs from scratch.  The add-on software is
 
directory hierarchies for DSAs from scratch.  The add-on software is
 
available via anonymous FTP from uu.psi.com in:
 
available via anonymous FTP from uu.psi.com in:
 +
 
   wp/src/wpp-addon.tar.Z
 
   wp/src/wpp-addon.tar.Z
 +
 
Whether you choose to use 'usconfig' or not, please retrieve and
 
Whether you choose to use 'usconfig' or not, please retrieve and
 
install the addon, and follow the instructions therein. You might
 
install the addon, and follow the instructions therein. You might
−
 
−
 
−
 
−
 
−
 
−
 
  
 
want to retrieve pilot-ps.tar.Z again also, as it contains an updated
 
want to retrieve pilot-ps.tar.Z again also, as it contains an updated
 
Administrator Guide.
 
Administrator Guide.
 +
 
Note that the wpp-addon.tar.Z file needs to be installed on top of
 
Note that the wpp-addon.tar.Z file needs to be installed on top of
 
the ISODE 7.0 distribution; it does not duplicate any of the ISODE
 
the ISODE 7.0 distribution; it does not duplicate any of the ISODE
 
7.0, you need to retrieve and generate that too.
 
7.0, you need to retrieve and generate that too.
 +
 
                               PP 6.0
 
                               PP 6.0
 +
 
PP is a Message Transfer Agent, intended for high volume message
 
PP is a Message Transfer Agent, intended for high volume message
 
switching, protocol conversion, and format conversion.  It is
 
switching, protocol conversion, and format conversion.  It is
Line 2,665: Line 2,791:
 
includes substantial changes based on feedback from using PP on many
 
includes substantial changes based on feedback from using PP on many
 
sites.
 
sites.
 +
 
o  PP is not proprietary and can be used for any purpose.  The only
 
o  PP is not proprietary and can be used for any purpose.  The only
 
   restriction is that suing of the authors for any damage the
 
   restriction is that suing of the authors for any damage the
 
   code may cause is not allowed.
 
   code may cause is not allowed.
 +
 
o  PP runs on a range of UNIX and UNIX-like operating systems,
 
o  PP runs on a range of UNIX and UNIX-like operating systems,
 
   including SUNOS, Ultrix, and BSD.  A full list of platforms on
 
   including SUNOS, Ultrix, and BSD.  A full list of platforms on
 
   which PP is know to run is included in the distribution.
 
   which PP is know to run is included in the distribution.
 +
 
o  Current modules include:
 
o  Current modules include:
 +
 
   -  X.400 (1984) P1 protocol.
 
   -  X.400 (1984) P1 protocol.
 +
 
   -  X.400 (1988) P1 protocol.
 
   -  X.400 (1988) P1 protocol.
 +
 
   -  Simple mail transfer protocol (SMTP), conformant to host
 
   -  Simple mail transfer protocol (SMTP), conformant to host
 
       requirements.
 
       requirements.
 +
 
   -  JNT mail (grey book) Protocol.
 
   -  JNT mail (grey book) Protocol.
 +
 
   -  UUCP mail transfer.
 
   -  UUCP mail transfer.
 +
 
   -  DECNET Mail-11 transfer
 
   -  DECNET Mail-11 transfer
 +
 
   -  Distribution list expansion and maintenance, using either a
 
   -  Distribution list expansion and maintenance, using either a
 
       file based mechanism or an X.500 directory.
 
       file based mechanism or an X.500 directory.
−
  -  RFC 822-based local delivery.
 
−
 
  
 +
  -  [[RFC822|RFC 822]]-based local delivery.
  
 +
  -  Delivery time processing of messages.
  
−
 
−
 
−
 
−
  -  Delivery time processing of messages.
 
 
   -  Conversion between X.400 and RFC-822 according to the latest
 
   -  Conversion between X.400 and RFC-822 according to the latest
 
       revision of RFC-1148, known as RFC-1148bis.
 
       revision of RFC-1148, known as RFC-1148bis.
 +
 
   -  Conversion support for reformatting body parts and headers.
 
   -  Conversion support for reformatting body parts and headers.
 +
 
   -  X-Window and line-based management console.
 
   -  X-Window and line-based management console.
 +
 
   -  Message Authorization checking.
 
   -  Message Authorization checking.
 +
 
   -  Reformatting support for "mail hub" operation.
 
   -  Reformatting support for "mail hub" operation.
 +
 
   -  X.500-based distribution list facility using the QUIPU
 
   -  X.500-based distribution list facility using the QUIPU
 
       directory.
 
       directory.
 +
 
   -  FAX interworking
 
   -  FAX interworking
 +
 
o  No User Agents (UAs) are included with PP.  However, procedural
 
o  No User Agents (UAs) are included with PP.  However, procedural
 
   access to the MTA is documented, to encourage others to write
 
   access to the MTA is documented, to encourage others to write
 
   or to port UAs.  Several existing UAs, such as MH, may be used
 
   or to port UAs.  Several existing UAs, such as MH, may be used
 
   with PP.
 
   with PP.
 +
 
o  It is expected that a Message Store to be used in conjunction
 
o  It is expected that a Message Store to be used in conjunction
 
   with PP (PPMS), and an associated X-Windows User Agent (XUA)
 
   with PP (PPMS), and an associated X-Windows User Agent (XUA)
 
   will be released on beta test in first quarter 92.
 
   will be released on beta test in first quarter 92.
 +
 
o  The core routing of PP 6.0 is table based.  DNS is used by the
 
o  The core routing of PP 6.0 is table based.  DNS is used by the
 
   SMTP channel.  The next version of PP will support Directory
 
   SMTP channel.  The next version of PP will support Directory
 
   Based routing, which may use X.500 or DNS.
 
   Based routing, which may use X.500 or DNS.
 +
 
o  PP 6.0 requires ISODE 7.0.
 
o  PP 6.0 requires ISODE 7.0.
 +
 
o  X-Windows release X11R4 (or greater) is needed by some of the
 
o  X-Windows release X11R4 (or greater) is needed by some of the
 
   management tools.  PP can be operated without these tools.
 
   management tools.  PP can be operated without these tools.
 +
 
o  Although PP is not "supported" per se (but see later), it does
 
o  Although PP is not "supported" per se (but see later), it does
 
   have a problem reporting address (bug reports (and fixes) are
 
   have a problem reporting address (bug reports (and fixes) are
 
   welcome):
 
   welcome):
 +
 
   RFC-822:  [email protected]
 
   RFC-822:  [email protected]
 
   X.400:    S=PP-Support; OU=CS; O=UCL;
 
   X.400:    S=PP-Support; OU=CS; O=UCL;
 
             PRMD=UK.AC; ADMD= ; C=GB;
 
             PRMD=UK.AC; ADMD= ; C=GB;
 +
 
o  The discussion group [email protected] is used as an open
 
o  The discussion group [email protected] is used as an open
 
   forum on PP; Contact [email protected] to be added
 
   forum on PP; Contact [email protected] to be added
 
   to this list.
 
   to this list.
−
 
−
 
−
 
−
 
−
 
−
 
−
 
  
 
o  The primary documentation for this release consists of a three
 
o  The primary documentation for this release consists of a three
Line 2,733: Line 2,872:
 
   of UNIX manual pages.  The sources to the User's Manual are in
 
   of UNIX manual pages.  The sources to the User's Manual are in
 
   LaTeX format.
 
   LaTeX format.
 +
 
                         PP Distribution Sites
 
                         PP Distribution Sites
 +
 
If you can FTP to the Internet from outside Europe, then use
 
If you can FTP to the Internet from outside Europe, then use
 
anonymous FTP to uu.psi.com [136.161.128.3] to retrieve the file pp-
 
anonymous FTP to uu.psi.com [136.161.128.3] to retrieve the file pp-
Line 2,739: Line 2,880:
 
tar image after being run through the compress program and is
 
tar image after being run through the compress program and is
 
approximately 3Mb in size.
 
approximately 3Mb in size.
 +
 
If you can FTP to the Internet from Europe, then use anonymous FTP to
 
If you can FTP to the Internet from Europe, then use anonymous FTP to
 
archive.eu.net [192.16.202.1] to retrieve the file pp-6.tar.Z in
 
archive.eu.net [192.16.202.1] to retrieve the file pp-6.tar.Z in
Line 2,744: Line 2,886:
 
image after being run through the compress program and is
 
image after being run through the compress program and is
 
approximately 3Mb in size.
 
approximately 3Mb in size.
 +
 
           ISODE/QUIPU and PP Platforms as of December 1991
 
           ISODE/QUIPU and PP Platforms as of December 1991
 +
 
Machine          OS                      ISODE  PP  Stacks  Notes
 
Machine          OS                      ISODE  PP  Stacks  Notes
 
====================================================================
 
====================================================================
Line 2,772: Line 2,916:
 
DEC              Ultrix 3.1D              7.0    5.2  TCP    7
 
DEC              Ultrix 3.1D              7.0    5.2  TCP    7
 
                 Ultrix 4.0                          X25
 
                 Ultrix 4.0                          X25
−
 
−
 
−
 
−
 
−
 
−
 
  
 
                 Ultrix 4.1
 
                 Ultrix 4.1
Line 2,828: Line 2,966:
 
--------------------------------------------------------------------
 
--------------------------------------------------------------------
  
−
 
+
Pyramid 9800    OSx 5.1 (4.3BSD/SVR3.2)  7.0    5.2 TCP      18
−
 
 
−
 
 
−
 
 
−
 
 
−
 
 
−
Pyramid 9800    OSx 5.1 (4.3BSD/SVR3.2)  7.0    5.2 TCP      18
 
 
Pyramid MIS
 
Pyramid MIS
 
--------------------------------------------------------------------
 
--------------------------------------------------------------------
Line 2,847: Line 2,979:
 
                                                     CLNS
 
                                                     CLNS
 
--------------------------------------------------------------------
 
--------------------------------------------------------------------
 +
 
Notes:
 
Notes:
 +
 
1.  NOT SNMP or VT
 
1.  NOT SNMP or VT
 +
 
2.  Little tested
 
2.  Little tested
 +
 
3.  Official upper layer
 
3.  Official upper layer
 +
 
4.  Prototype only!
 
4.  Prototype only!
 +
 
5.  Planned port
 
5.  Planned port
 +
 
6.  Being worked on!
 
6.  Being worked on!
 +
 
7.  3.1D binaries compiled under 4.2
 
7.  3.1D binaries compiled under 4.2
 +
 
8.  Only QUIPU confirmed
 
8.  Only QUIPU confirmed
 +
 
9.  Not QUIPU
 
9.  Not QUIPU
 +
 
10.  Need "-Dregister=" in CONFIG.make
 
10.  Need "-Dregister=" in CONFIG.make
 +
 
11.  Need bug-fix no. 5 from [email protected]. not SNMP,VT or
 
11.  Need bug-fix no. 5 from [email protected]. not SNMP,VT or
 
     FTAM-FTP gateway
 
     FTAM-FTP gateway
 +
 
12.  No VT, QUIPU not tested
 
12.  No VT, QUIPU not tested
 +
 
13.  Models 80 and 95
 
13.  Models 80 and 95
 +
 
14.  NOT SNMP or VT,PP and X.25 requires patches available from
 
14.  NOT SNMP or VT,PP and X.25 requires patches available from
 
     X-Tel
 
     X-Tel
 +
 
15.  Using MacTCP
 
15.  Using MacTCP
  
 +
16.  Only QUIPU tested, built using BSD43 config
  
 +
17.  Need bug-fix no. 6 from [email protected]
  
 +
18.  Built using BSD config, no VT or SNMP
  
−
 
−
 
−
 
−
 
−
16.  Only QUIPU tested, built using BSD43 config
 
−
17.  Need bug-fix no. 6 from [email protected]
 
−
18.  Built using BSD config, no VT or SNMP
 
 
The above tables do not refer to beta releases of ISODE  and PP more
 
The above tables do not refer to beta releases of ISODE  and PP more
 
recent than the public ISODE-7.0 or PP-5.2 releases.  The above table
 
recent than the public ISODE-7.0 or PP-5.2 releases.  The above table
 
is generated from reports sent to bug-ISODE and pp-support.  There is
 
is generated from reports sent to bug-ISODE and pp-support.  There is
 
no guarantee the information is correct.
 
no guarantee the information is correct.
 +
 
Appendix D:  Sample X.500 Input File and Restricted Character List
 
Appendix D:  Sample X.500 Input File and Restricted Character List
 +
 
Below is a sample datafile that illustrates the format for providing
 
Below is a sample datafile that illustrates the format for providing
 
data about persons at your site to be loaded into the ESnet DSA.
 
data about persons at your site to be loaded into the ESnet DSA.
Line 2,889: Line 3,035:
 
the file and will try to accommodate any specific needs you may have
 
the file and will try to accommodate any specific needs you may have
 
to any extent that is reasonable.
 
to any extent that is reasonable.
 +
 
#
 
#
 
#        Sample Data File for Bulk Loading X.500 Database
 
#        Sample Data File for Bulk Loading X.500 Database
Line 2,912: Line 3,059:
 
Cathy White,4016,[email protected],                            18
 
Cathy White,4016,[email protected],                            18
 
<end-of-file>
 
<end-of-file>
 +
 
Comment lines at the beginning of the file convey relevant formatting
 
Comment lines at the beginning of the file convey relevant formatting
 
information.
 
information.
  
 +
Following comment lines, each data line contains information about
 +
one person.
  
−
 
+
Fields within a single data line are separated by a delimiter
−
 
 
−
 
 
−
 
 
−
 
 
−
Following comment lines, each data line contains information about
 
−
one person.
 
−
Fields within a single data line are separated by a delimiter
 
 
character.  You specify the delimiter character you wish to use in
 
character.  You specify the delimiter character you wish to use in
 
the comment section; be sure to choose a delimiter which does not
 
the comment section; be sure to choose a delimiter which does not
 
appear as a legitimate character in any field of a data line.
 
appear as a legitimate character in any field of a data line.
 +
 
You may provide all or part of the attribute types listed in the
 
You may provide all or part of the attribute types listed in the
 
table in Section 2.5 (commonName is required).  In the comment
 
table in Section 2.5 (commonName is required).  In the comment
 
section, you must indicate which attribute types are contained in
 
section, you must indicate which attribute types are contained in
 
each field of a data line.
 
each field of a data line.
 +
 
Each data line must contain the same number of fields and the same
 
Each data line must contain the same number of fields and the same
 
order of fields (i.e. same order of attribute types).  Two successive
 
order of fields (i.e. same order of attribute types).  Two successive
 
delimiters indicated a null value (eof is a considered a field
 
delimiters indicated a null value (eof is a considered a field
 
delimiter).
 
delimiter).
 +
 
The characters "=", "&", "$", and "#" are NEVER allowed in any
 
The characters "=", "&", "$", and "#" are NEVER allowed in any
 
attribute value.
 
attribute value.
 +
 
Below is a discussion of relevant lines of the sample datafile.
 
Below is a discussion of relevant lines of the sample datafile.
 +
 
Line 1      The delimiter character is identified as a comma (,).
 
Line 1      The delimiter character is identified as a comma (,).
 +
 
Line 2      Field # 1 is identified as containing the commonName
 
Line 2      Field # 1 is identified as containing the commonName
 
               attribute.
 
               attribute.
 +
 
Line 3      Field # 2 is identified as containing the telephoneNumber
 
Line 3      Field # 2 is identified as containing the telephoneNumber
 
               attribute.  The actual data value is a 4-digit
 
               attribute.  The actual data value is a 4-digit
 
               extension.
 
               extension.
 +
 
Lines 4,5  Identify the area code and prefix which apply to all
 
Lines 4,5  Identify the area code and prefix which apply to all
 
               4-digit extensions in the datafile.  If your actual
 
               4-digit extensions in the datafile.  If your actual
 
               data values already contain area code and/or prefix,
 
               data values already contain area code and/or prefix,
 
               then there would be no need to indicate default values.
 
               then there would be no need to indicate default values.
 +
 
Line 6      Field # 3 is identified as containing the rfc822Mailbox
 
Line 6      Field # 3 is identified as containing the rfc822Mailbox
 
               attribute.
 
               attribute.
 +
 
Line 7      Field # 4 is identified as containing the
 
Line 7      Field # 4 is identified as containing the
 
               facsimileTelephoneNumber attribute.
 
               facsimileTelephoneNumber attribute.
 +
 
Line 8      Identifies the default value for
 
Line 8      Identifies the default value for
 
               facsimileTelephoneNumber.  If field 4 is missing in a
 
               facsimileTelephoneNumber.  If field 4 is missing in a
 
               data line, the default value will be applied.
 
               data line, the default value will be applied.
 +
 
Lines 9-12  Identify the value of the postalAddress attribute which
 
Lines 9-12  Identify the value of the postalAddress attribute which
  
 +
              applies to all entries.
  
−
 
−
 
−
 
−
 
−
 
−
              applies to all entries.
 
 
Line 13  commonName= Chris Anderson
 
Line 13  commonName= Chris Anderson
 
         surName= Anderson
 
         surName= Anderson
Line 2,972: Line 3,122:
 
                         P.O. Box 5509
 
                         P.O. Box 5509
 
                         Livermore, California 94552
 
                         Livermore, California 94552
 +
 
Line 14  commonName= Lila Brown
 
Line 14  commonName= Lila Brown
 
         surName= Brown
 
         surName= Brown
Line 2,980: Line 3,131:
 
                         P.O. Box 5509
 
                         P.O. Box 5509
 
                         Livermore, California 94552
 
                         Livermore, California 94552
 +
 
Line 15  commonName= Bob Green
 
Line 15  commonName= Bob Green
 
         surName= Green
 
         surName= Green
Line 2,988: Line 3,140:
 
                         P.O. Box 5509
 
                         P.O. Box 5509
 
                         Livermore, California 94552
 
                         Livermore, California 94552
 +
 
Line 16  commonName= Max Jones
 
Line 16  commonName= Max Jones
 
         surName= Jones
 
         surName= Jones
Line 2,996: Line 3,149:
 
                         P.O. Box 5509
 
                         P.O. Box 5509
 
                         Livermore, California 94552
 
                         Livermore, California 94552
 +
 
Line 17  commonName= Dave Smith
 
Line 17  commonName= Dave Smith
 
         surName= Smith
 
         surName= Smith
Line 3,004: Line 3,158:
 
                         P.O. Box 5509
 
                         P.O. Box 5509
 
                         Livermore, California 94552
 
                         Livermore, California 94552
−
 
−
 
−
 
−
 
−
 
−
 
−
 
−
 
  
 
Line 18  commonName= Cathy White
 
Line 18  commonName= Cathy White
Line 3,021: Line 3,167:
 
                         P.O. Box 5509
 
                         P.O. Box 5509
 
                         Livermore, California 94552
 
                         Livermore, California 94552
 +
 
Appendix E:  ESnet Backbone Sites
 
Appendix E:  ESnet Backbone Sites
 +
 
                         Government Agencies
 
                         Government Agencies
 +
 
U.S. Department of Energy, Office of Energy Research (DOE)
 
U.S. Department of Energy, Office of Energy Research (DOE)
 
Germantown, Maryland  USA
 
Germantown, Maryland  USA
 +
 
U.S. Department of Energy, San Francisco Office (SAN)
 
U.S. Department of Energy, San Francisco Office (SAN)
 
Oakland, California  USA
 
Oakland, California  USA
 +
 
                         National Laboratories
 
                         National Laboratories
 +
 
NASA Ames Research Center (AMES, FIX-WEST)
 
NASA Ames Research Center (AMES, FIX-WEST)
 
Mountain View, California  USA
 
Mountain View, California  USA
 +
 
Argonne National Laboratory (ANL)
 
Argonne National Laboratory (ANL)
 
Argonne, Illinois  USA
 
Argonne, Illinois  USA
 +
 
Brookhaven National Laboratory (BNL)
 
Brookhaven National Laboratory (BNL)
 
Upton, New York  USA
 
Upton, New York  USA
 +
 
Continuous Electron Beam Accelerator Facility (CEBAF)
 
Continuous Electron Beam Accelerator Facility (CEBAF)
 
Newport News, Virginia  USA
 
Newport News, Virginia  USA
 +
 
Fermi National Accelerator Laboratory (FNAL)
 
Fermi National Accelerator Laboratory (FNAL)
 
Batavia, Illinois  USA
 
Batavia, Illinois  USA
 +
 
Lawrence Berkeley Laboratory (LBL)
 
Lawrence Berkeley Laboratory (LBL)
 
Berkeley, California  USA
 
Berkeley, California  USA
 +
 
Lawrence Livermore National Laboratory (LLNL)
 
Lawrence Livermore National Laboratory (LLNL)
 
Livermore, California  USA
 
Livermore, California  USA
 +
 
Los Alamos National Laboratory (LANL)
 
Los Alamos National Laboratory (LANL)
 
Los Alamos, New Mexico  USA
 
Los Alamos, New Mexico  USA
 +
 
Oak Ridge National Laboratory (ORNL)
 
Oak Ridge National Laboratory (ORNL)
 
Oak Ridge, Tennessee  USA
 
Oak Ridge, Tennessee  USA
−
 
−
 
−
 
−
 
−
 
−
 
−
 
  
 
Pacific Northwest Laboratory (PNL)
 
Pacific Northwest Laboratory (PNL)
 
Richland, Washington  USA
 
Richland, Washington  USA
 +
 
Princeton Plasma Physics Laboratory (PPPL)
 
Princeton Plasma Physics Laboratory (PPPL)
 
Princeton, New Jersey  USA
 
Princeton, New Jersey  USA
 +
 
Sandia National Laboratory, Albuquerque (SNLA)
 
Sandia National Laboratory, Albuquerque (SNLA)
 
Albuquerque, New Mexico  USA
 
Albuquerque, New Mexico  USA
 +
 
Stanford Linear Accelerator Center (SLAC)
 
Stanford Linear Accelerator Center (SLAC)
 
Menlo Park, California  USA
 
Menlo Park, California  USA
 +
 
Superconducting Super Collider (SSC)
 
Superconducting Super Collider (SSC)
 
Dallas, Texas  USA
 
Dallas, Texas  USA
 +
 
                             Universities
 
                             Universities
 +
 
California Institute of Technology (CIT)
 
California Institute of Technology (CIT)
 
Pasadena, California  USA
 
Pasadena, California  USA
 +
 
Florida State University (FSU)
 
Florida State University (FSU)
 
Tallahassee, Florida  USA
 
Tallahassee, Florida  USA
 +
 
Iowa State University (ISU)
 
Iowa State University (ISU)
 
Ames, Iowa  USA
 
Ames, Iowa  USA
 +
 
Massachusetts Institute of Technology (MIT)
 
Massachusetts Institute of Technology (MIT)
 
Cambridge, Massachusetts  USA
 
Cambridge, Massachusetts  USA
 +
 
New York University (NYU)
 
New York University (NYU)
 
Upton, New York  USA
 
Upton, New York  USA
 +
 
Oak Ridge Associated Universities (ORAU)
 
Oak Ridge Associated Universities (ORAU)
 
Oak Ridge, Tennessee  USA
 
Oak Ridge, Tennessee  USA
 +
 
University of California, Los Angeles (UCLA)
 
University of California, Los Angeles (UCLA)
 
Westwood, California  USA
 
Westwood, California  USA
 +
 
University of Maryland (UMD, FIX-EAST)
 
University of Maryland (UMD, FIX-EAST)
 
College Park, Maryland  USA
 
College Park, Maryland  USA
 +
 
University of Texas, Austin (UTA)
 
University of Texas, Austin (UTA)
 
Austin, Texas  USA
 
Austin, Texas  USA
 +
 
                         Commercial Entities
 
                         Commercial Entities
 +
 
General Atomics (GA)
 
General Atomics (GA)
 
San Diego, California  USA
 
San Diego, California  USA
−
 
−
 
−
 
−
 
−
 
−
 
  
 
Office of Science and Technology Information (OSTI)
 
Office of Science and Technology Information (OSTI)
 
Oak Ridge, Tennessee  USA
 
Oak Ridge, Tennessee  USA
 +
 
Science Applications, Incorporated (SAIC)
 
Science Applications, Incorporated (SAIC)
 
McLean, Virginia  USA
 
McLean, Virginia  USA
 +
 
Appendix F:  Local Site Contacts for DOE Naming Authorities
 
Appendix F:  Local Site Contacts for DOE Naming Authorities
 +
 
Below is a list of all Department of Energy GOSIP Site Authorities
 
Below is a list of all Department of Energy GOSIP Site Authorities
 
for OSI registration and addressing.  This information was obtained
 
for OSI registration and addressing.  This information was obtained
 
from the DoE GOSIP On-Line Information System (DOE-GOIS), dated
 
from the DoE GOSIP On-Line Information System (DOE-GOIS), dated
 
November 18, 1991.
 
November 18, 1991.
 +
 
Marian F. Sotel
 
Marian F. Sotel
 
Director, Information management Division
 
Director, Information management Division
 
U.S. Department of Energy
 
U.S. Department of Energy
 
DOE Field Office, Albuquerque
 
DOE Field Office, Albuquerque
 +
 
Dennis Jensen
 
Dennis Jensen
 
Ames Laboratory
 
Ames Laboratory
Line 3,111: Line 3,279:
 
Ames, IA 50011-3020
 
Ames, IA 50011-3020
 
(515) 294-7909
 
(515) 294-7909
 +
 
Linda Winkler
 
Linda Winkler
 
Argonne National Laboratory
 
Argonne National Laboratory
 
Argonne, IL 60439
 
Argonne, IL 60439
 
(708) 972-7236
 
(708) 972-7236
 +
 
R. E. Kremer
 
R. E. Kremer
 
Manager, Resource Automation
 
Manager, Resource Automation
 
U.S. Department of Energy
 
U.S. Department of Energy
 
Bettis Atomic Power laboratory
 
Bettis Atomic Power laboratory
 +
 
Gary Ragsdale
 
Gary Ragsdale
 
Manager, Information Services
 
Manager, Information Services
Line 3,125: Line 3,296:
 
905 NE 11th Avenue
 
905 NE 11th Avenue
 
Portland, OR 97232
 
Portland, OR 97232
 +
 
Wayne Larson
 
Wayne Larson
 
Head of Data Communications Unit
 
Head of Data Communications Unit
Line 3,131: Line 3,303:
 
905 NE 11th Avenue
 
905 NE 11th Avenue
 
Portland, OR 97232
 
Portland, OR 97232
−
 
−
 
−
 
−
 
−
 
−
 
−
 
  
 
George Rabinowitz
 
George Rabinowitz
Line 3,144: Line 3,309:
 
Upton, New York 11973
 
Upton, New York 11973
 
(516) 282-7637
 
(516) 282-7637
 +
 
Donna A. Dyxin
 
Donna A. Dyxin
 
Communications Specialist
 
Communications Specialist
Line 3,150: Line 3,316:
 
9800 South Cass Avenue
 
9800 South Cass Avenue
 
Argonne, IL 60439
 
Argonne, IL 60439
 +
 
Elaine R. Liebrecht
 
Elaine R. Liebrecht
 
System Manager and Planning Supervisor
 
System Manager and Planning Supervisor
Line 3,156: Line 3,323:
 
Miamisburg, OH 45343-3000
 
Miamisburg, OH 45343-3000
 
(FTS) 774-3733 or (513) 865-3733
 
(FTS) 774-3733 or (513) 865-3733
 +
 
Jeffrey J. Johnson
 
Jeffrey J. Johnson
 
Communications Supervisor
 
Communications Supervisor
Line 3,162: Line 3,330:
 
Miamisburg, OH 45343-3000
 
Miamisburg, OH 45343-3000
 
(FTS) 774-4230 or (513) 865-4230
 
(FTS) 774-4230 or (513) 865-4230
 +
 
Paul P. Herr
 
Paul P. Herr
 
U.S. Department of Energy
 
U.S. Department of Energy
 
Energy Information Agency
 
Energy Information Agency
 
(202) 586-7318
 
(202) 586-7318
 +
 
William H. Foster
 
William H. Foster
 
U.S. Department of Energy
 
U.S. Department of Energy
 
Energy Information Agency
 
Energy Information Agency
 
(202) 586-6310
 
(202) 586-6310
 +
 
Mark O. Kaletka
 
Mark O. Kaletka
 
Data Communications Group Leader, Computing Div.
 
Data Communications Group Leader, Computing Div.
Line 3,176: Line 3,347:
 
Batavia, IL 60510
 
Batavia, IL 60510
 
(708) 840-2965
 
(708) 840-2965
 +
 
David A. Mackler
 
David A. Mackler
 
Grand Junction Project Office
 
Grand Junction Project Office
 
(FTS) 326-6412
 
(FTS) 326-6412
−
 
−
 
−
 
−
 
−
 
−
 
−
 
  
 
Wayne L. Selfors
 
Wayne L. Selfors
 
Grand Junction Project Office
 
Grand Junction Project Office
 
(FTS) 326-6525
 
(FTS) 326-6525
 +
 
Gerald F. Chappell
 
Gerald F. Chappell
 
Director, ITSO
 
Director, ITSO
Line 3,196: Line 3,362:
 
Washington D.C., 20545
 
Washington D.C., 20545
 
(FTS) 233-3685 or (301) 903-3685
 
(FTS) 233-3685 or (301) 903-3685
 +
 
Joe Diel
 
Joe Diel
 
Supervisor, Biomathematics Group
 
Supervisor, Biomathematics Group
 
ITRI
 
ITRI
 +
 
David H. Robinson
 
David H. Robinson
 
Section Supervisor, Information Systems
 
Section Supervisor, Information Systems
Line 3,206: Line 3,374:
 
Kansas City, MO 64141-6159
 
Kansas City, MO 64141-6159
 
(FTS) 997-3690 or (816) 997-3690
 
(FTS) 997-3690 or (816) 997-3690
 +
 
Robert M. Jensen
 
Robert M. Jensen
 
Supervisory Engineer, Information Systems
 
Supervisory Engineer, Information Systems
Line 3,213: Line 3,382:
 
Kansas City, MO 64141-6159
 
Kansas City, MO 64141-6159
 
(FTS) 997-5538 or (816) 997-5538
 
(FTS) 997-5538 or (816) 997-5538
 +
 
Russell Wright
 
Russell Wright
 
Lawrence Berkeley Laboratories
 
Lawrence Berkeley Laboratories
Line 3,218: Line 3,388:
 
Berkeley, CA 94720
 
Berkeley, CA 94720
 
(510) 486-6965
 
(510) 486-6965
 +
 
William A. Lokke
 
William A. Lokke
 
Associate Director for Computation
 
Associate Director for Computation
 
Lawrence Livermore National Lab
 
Lawrence Livermore National Lab
 
(FTS) 532-9870 or (669) 422-9870
 
(FTS) 532-9870 or (669) 422-9870
 +
 
Philip Wood/Glenn Michel
 
Philip Wood/Glenn Michel
 
Los Alamos National Laboratory
 
Los Alamos National Laboratory
Line 3,227: Line 3,399:
 
(FTS) 843-1845 or (FTS) 843-2598
 
(FTS) 843-1845 or (FTS) 843-2598
  
 +
Robert Bruen
 +
MIT Laboratory for Nuclear Science
 +
Computer Facilities Manager
 +
Massachusetts Institute of Tech.
 +
Cambridge, MA
  
−
 
−
 
−
 
−
 
−
 
−
 
−
 
−
Robert Bruen
 
−
MIT Laboratory for Nuclear Science
 
−
Computer Facilities Manager
 
−
Massachusetts Institute of Tech.
 
−
Cambridge, MA
 
 
Mark Cerullo
 
Mark Cerullo
 
Morgantown Energy Technology Center
 
Morgantown Energy Technology Center
 
(FTS) 923-4345
 
(FTS) 923-4345
 +
 
Hank Latham
 
Hank Latham
 
NVRSN
 
NVRSN
 
(FTS) 575-7646
 
(FTS) 575-7646
 +
 
Bill Morrison
 
Bill Morrison
 
Network Specialist
 
Network Specialist
Line 3,253: Line 3,420:
 
Tupman, CA 93276
 
Tupman, CA 93276
 
(FTS) 797-6933 or (805) 763-6933
 
(FTS) 797-6933 or (805) 763-6933
 +
 
Mary Ann Jones
 
Mary Ann Jones
 
DOE Field Office, Nevada
 
DOE Field Office, Nevada
 +
 
Bill Freberg
 
Bill Freberg
 
Computer Sciences Corporation
 
Computer Sciences Corporation
 
DOE Field Office, Nevada
 
DOE Field Office, Nevada
 +
 
Roger Hardwick
 
Roger Hardwick
 
Project Director
 
Project Director
Line 3,265: Line 3,435:
 
Las Vegas, NV 89103
 
Las Vegas, NV 89103
 
(702) 873-6200
 
(702) 873-6200
 +
 
John Gandi
 
John Gandi
 
U.S. Department of Energy
 
U.S. Department of Energy
Line 3,272: Line 3,443:
 
Las Vegas, NV 89109
 
Las Vegas, NV 89109
 
(702) 794-7954
 
(702) 794-7954
 +
 
Benny Goodman
 
Benny Goodman
 
U.S. Department of Energy
 
U.S. Department of Energy
 
OSTI
 
OSTI
−
 
−
 
−
 
−
 
−
 
−
 
  
 
Raymond F. Cook
 
Raymond F. Cook
 
U.S. Department of Energy
 
U.S. Department of Energy
 
OSTI
 
OSTI
 +
 
D. M. Turnpin
 
D. M. Turnpin
 
Martin Marietta Energy Systems, Inc
 
Martin Marietta Energy Systems, Inc
Line 3,291: Line 3,458:
 
Oak Ridge, TN 37831-8227
 
Oak Ridge, TN 37831-8227
 
(FTS) 626-8848 or (615) 576-8848
 
(FTS) 626-8848 or (615) 576-8848
 +
 
T. E. Birchfield
 
T. E. Birchfield
 
Supervisor, Electronic Informations Delivery Sect.
 
Supervisor, Electronic Informations Delivery Sect.
Line 3,298: Line 3,466:
 
Oak Ridge, TN 37831-6283
 
Oak Ridge, TN 37831-6283
 
(FTS) 624-4635 or (615) 574-4635
 
(FTS) 624-4635 or (615) 574-4635
 +
 
Bobby Brumley
 
Bobby Brumley
 
TRESP Associates
 
TRESP Associates
 
DOE Field Office, Oak Ridge
 
DOE Field Office, Oak Ridge
 +
 
Mike Letterman
 
Mike Letterman
 
TRESP Associates
 
TRESP Associates
 
DOE Field Office, Oak Ridge
 
DOE Field Office, Oak Ridge
 +
 
S. Dean Carpenter
 
S. Dean Carpenter
 
Department Head, Communications
 
Department Head, Communications
 
Mason and Hanger
 
Mason and Hanger
 
Pantex Plant
 
Pantex Plant
 +
 
Wayne C. Phillips
 
Wayne C. Phillips
 
Section Head, Internal Communications
 
Section Head, Internal Communications
 
Mason and Hanger
 
Mason and Hanger
 
Pantex Plant
 
Pantex Plant
 +
 
A. J. Lelekacs
 
A. J. Lelekacs
 
Sr. Networking Engineer
 
Sr. Networking Engineer
Line 3,320: Line 3,493:
 
Largo, FL 34649-2908
 
Largo, FL 34649-2908
  
 +
Paul A. Funk
 +
Site Access Coordinator
 +
Princeton Plasma Physics Laboratory
 +
P.O. Box 451
 +
Princeton, NJ 08543
 +
(609) 243-3403
  
−
 
+
John Murphy
−
 
+
Branch Chief, Information and Communication Mgmt
−
 
 
−
 
 
−
 
 
−
 
 
−
 
 
−
 
 
−
 
 
−
Paul A. Funk
 
−
Site Access Coordinator
 
−
Princeton Plasma Physics Laboratory
 
−
P.O. Box 451
 
−
Princeton, NJ 08543
 
−
(609) 243-3403
 
−
John Murphy
 
−
Branch Chief, Information and Communication Mgmt
 
 
U.S. Department of Energy
 
U.S. Department of Energy
 
DOE Field Office, Richland
 
DOE Field Office, Richland
Line 3,343: Line 3,507:
 
Richland, WA 99352
 
Richland, WA 99352
 
(FTS) 444-7543 or (509) 376-7543
 
(FTS) 444-7543 or (509) 376-7543
 +
 
Mike Schmidt
 
Mike Schmidt
 
Telecom & Network Services IRM
 
Telecom & Network Services IRM
Line 3,350: Line 3,515:
 
Richland, WA 99352
 
Richland, WA 99352
 
(FTS) 444-7739 or (509) 376-7739
 
(FTS) 444-7739 or (509) 376-7739
 +
 
Dwayne Ramsey
 
Dwayne Ramsey
 
Information Resources Management Division
 
Information Resources Management Division
Line 3,355: Line 3,521:
 
DOE Field Office, San Francisco
 
DOE Field Office, San Francisco
 
(FTS) 536-4302
 
(FTS) 536-4302
 +
 
W. F. Mason
 
W. F. Mason
 
Central Computing Systems Manager
 
Central Computing Systems Manager
Line 3,361: Line 3,528:
 
Albuquerque, NM 87185
 
Albuquerque, NM 87185
 
(FTS) 845-8059 or (505) 845-8059
 
(FTS) 845-8059 or (505) 845-8059
 +
 
Harry R. Holden
 
Harry R. Holden
 
U.S. Department of Energy
 
U.S. Department of Energy
Line 3,367: Line 3,535:
 
Aiken, SC 29802
 
Aiken, SC 29802
 
(FTS) 239-1118 or (803) 725-1118
 
(FTS) 239-1118 or (803) 725-1118
−
 
−
 
−
 
−
 
−
 
−
 
−
 
−
 
−
 
−
 
−
 
−
 
  
 
Reggie Peagler
 
Reggie Peagler
Line 3,386: Line 3,542:
 
Aiken, SC 29808
 
Aiken, SC 29808
 
(FTS) 239-3418 or (803) 557-3418
 
(FTS) 239-3418 or (803) 557-3418
 +
 
Wade A. Gaines
 
Wade A. Gaines
 
Acting ADP Manager
 
Acting ADP Manager
Line 3,392: Line 3,549:
 
Samuel Elbert Building
 
Samuel Elbert Building
 
Elberton, GA 30635
 
Elberton, GA 30635
 +
 
Paul Richard
 
Paul Richard
 
Southwestern Power Administration
 
Southwestern Power Administration
 
(FTS) 745-7482
 
(FTS) 745-7482
 +
 
Dr. R. Les Cottrell
 
Dr. R. Les Cottrell
 
Assistant Director, SLAC Computer Services
 
Assistant Director, SLAC Computer Services
Line 3,400: Line 3,559:
 
P.O. Box 4349
 
P.O. Box 4349
 
Stanford, CA 94309
 
Stanford, CA 94309
 +
 
John Lucero
 
John Lucero
 
Systems Analyst, Management Systems
 
Systems Analyst, Management Systems
Line 3,407: Line 3,567:
 
Carlsbad, NM 88221
 
Carlsbad, NM 88221
 
(FTS) 571-8459 or (505) 887-8459
 
(FTS) 571-8459 or (505) 887-8459
 +
 
Lawrence Bluhm
 
Lawrence Bluhm
 
Sr. Systems Analyst, Management Systems
 
Sr. Systems Analyst, Management Systems
Line 3,414: Line 3,575:
 
Carlsbad, NM 88221
 
Carlsbad, NM 88221
 
(FTS) 571-8459 or (505) 887-8459
 
(FTS) 571-8459 or (505) 887-8459
 +
 
Ben Sandoval
 
Ben Sandoval
 
Western Area Power Administration
 
Western Area Power Administration
 
(FTS) 327-7470
 
(FTS) 327-7470
 +
 
John Sewell
 
John Sewell
 
Western Area Power Administration
 
Western Area Power Administration
 
(FTS) 327-7407
 
(FTS) 327-7407
  
 +
Appendix G:  Recommended Reading
  
 +
                    RFCs (Request For Comments)
  
−
 
−
 
−
 
−
 
−
 
−
Appendix G:  Recommended Reading
 
−
                    RFCs (Request For Comments)
 
 
The following RFCs may be obtained from the ESnet Information Server.
 
The following RFCs may be obtained from the ESnet Information Server.
 
They are stored in the directory [ANONYMOUS.RFCS].  They may be
 
They are stored in the directory [ANONYMOUS.RFCS].  They may be
 
retrieved via anonymous FTP (nic.es.net, 128.55.32.3) or DECnet copy
 
retrieved via anonymous FTP (nic.es.net, 128.55.32.3) or DECnet copy
 
(ESNIC::, 41.174).
 
(ESNIC::, 41.174).
 +
 
RFC1328  X.400 1988 to 1984 downgrading.  Hardcastle-Kille, S.E.  1992
 
RFC1328  X.400 1988 to 1984 downgrading.  Hardcastle-Kille, S.E.  1992
 
   May; 5 p. (Format: TXT=10006 bytes)
 
   May; 5 p. (Format: TXT=10006 bytes)
−
RFC1327  Mapping Between X.400 (1988) /ISO 10021 and RFC 822.
+
 
 +
RFC1327  Mapping Between X.400 (1988) /ISO 10021 and [[RFC822|RFC 822]].
 
   Hardcastle-Kille, S.E.  1992 May; 113 p. (Format: TXT=228598 bytes)
 
   Hardcastle-Kille, S.E.  1992 May; 113 p. (Format: TXT=228598 bytes)
 +
 
RFC1309  Technical overview of directory services using the X.500
 
RFC1309  Technical overview of directory services using the X.500
 
   protocol.  Weider, C.; Reynolds, J.K.; Heker, S.  1992 March; 4 p.
 
   protocol.  Weider, C.; Reynolds, J.K.; Heker, S.  1992 March; 4 p.
 
   (Format: TXT=35694 bytes)
 
   (Format: TXT=35694 bytes)
 +
 
RFC1308  Executive Introduction to Directory Services Using the X.500
 
RFC1308  Executive Introduction to Directory Services Using the X.500
 
   Protocol.  Weider, C.; Reynolds, J.K.  1992 March; 4 p. (Format:
 
   Protocol.  Weider, C.; Reynolds, J.K.  1992 March; 4 p. (Format:
 
   TXT=9392 bytes)
 
   TXT=9392 bytes)
 +
 
RFC1295  North American Directory Forum.  User bill of rights for
 
RFC1295  North American Directory Forum.  User bill of rights for
 
   entries and listing in the public directory.  1992 January; 2 p.
 
   entries and listing in the public directory.  1992 January; 2 p.
 
   (Format: TXT=3502 bytes)
 
   (Format: TXT=3502 bytes)
 +
 
RFC1292  Lang, R.; Wright, R.  Catalog of Available X.500
 
RFC1292  Lang, R.; Wright, R.  Catalog of Available X.500
 
   Implementations. 1991 December; 103 p. (Format: TXT=129468 bytes)
 
   Implementations. 1991 December; 103 p. (Format: TXT=129468 bytes)
 +
 
RFC1279  Hardcastle-Kille, S.E.  X.500 and domains.  1991 November; 13
 
RFC1279  Hardcastle-Kille, S.E.  X.500 and domains.  1991 November; 13
 
   p. (Format: TXT=26669, PS=170029 bytes)
 
   p. (Format: TXT=26669, PS=170029 bytes)
 +
 
RFC1278  Hardcastle-Kille, S.E.  String encoding of presentation
 
RFC1278  Hardcastle-Kille, S.E.  String encoding of presentation
 
   address. 1991 November; 5 p. (Format: TXT=10256, PS=128696 bytes)
 
   address. 1991 November; 5 p. (Format: TXT=10256, PS=128696 bytes)
 +
 
RFC1277  Hardcastle-Kille, S.E.  Encoding network addresses to support
 
RFC1277  Hardcastle-Kille, S.E.  Encoding network addresses to support
 
   operations over non-OSI lower layers.  1991 November; 10 p.
 
   operations over non-OSI lower layers.  1991 November; 10 p.
 
   (Format: TXT=22254, PS=176169 bytes)
 
   (Format: TXT=22254, PS=176169 bytes)
 +
 
RFC1276  Hardcastle-Kille, S.E.  Replication and distributed operations
 
RFC1276  Hardcastle-Kille, S.E.  Replication and distributed operations
 
   extensions to provide an Internet directory using X.500. 1991
 
   extensions to provide an Internet directory using X.500. 1991
 
   November; 17 p. (Format: TXT=33731, PS=217170 bytes)
 
   November; 17 p. (Format: TXT=33731, PS=217170 bytes)
 +
 
RFC1275  Hardcastle-Kille, S.E.  Replication requirements to provide an
 
RFC1275  Hardcastle-Kille, S.E.  Replication requirements to provide an
 
   Internet directory using X.500.  1991 November; 2 p. (Format:
 
   Internet directory using X.500.  1991 November; 2 p. (Format:
 
   TXT=4616, PS=83736 bytes)
 
   TXT=4616, PS=83736 bytes)
−
 
−
 
−
 
−
 
−
 
−
 
−
 
  
 
RFC1274  Kille, S.E.; Barker, P.  COSINE and Internet X.500 schema. 1991
 
RFC1274  Kille, S.E.; Barker, P.  COSINE and Internet X.500 schema. 1991
 
   November; 60 p. (Format: TXT=92827 bytes)
 
   November; 60 p. (Format: TXT=92827 bytes)
 +
 
RFC1255  North American Directory Forum.  Naming scheme for c=US. 1991
 
RFC1255  North American Directory Forum.  Naming scheme for c=US. 1991
−
   September; 25 p. (Format: TXT=53783 bytes)  (Obsoletes RFC 1218)
+
   September; 25 p. (Format: TXT=53783 bytes)  (Obsoletes [[RFC1218|RFC 1218]])
 +
 
 
RFC1249  Howes, T.; Smith, M.; Beecher, B.  DIXIE protocol
 
RFC1249  Howes, T.; Smith, M.; Beecher, B.  DIXIE protocol
 
   specification.  1991 August; 10 p. (Format: TXT=20693 bytes)
 
   specification.  1991 August; 10 p. (Format: TXT=20693 bytes)
 +
 
RFC1202  Rose, M.T.  Directory Assistance service.  1991 February; 11 p.
 
RFC1202  Rose, M.T.  Directory Assistance service.  1991 February; 11 p.
 
   (Format: TXT=21645 bytes)
 
   (Format: TXT=21645 bytes)
 +
 
RFC1006  Rose, M.T.; Cass, D.E.  ISO transport services on top of the
 
RFC1006  Rose, M.T.; Cass, D.E.  ISO transport services on top of the
 
   TCP: Version 3.  1987 May; 17 p. (Format: TXT=31935 bytes)
 
   TCP: Version 3.  1987 May; 17 p. (Format: TXT=31935 bytes)
 +
 
                       Non Published Working Notes
 
                       Non Published Working Notes
 +
 
"A String Representation of Distinguished Names", S.E. Hardcastle-Kille,
 
"A String Representation of Distinguished Names", S.E. Hardcastle-Kille,
 
   01/30/1992.
 
   01/30/1992.
 +
 
   The OSI Directory uses distinguished names as the primary keys to
 
   The OSI Directory uses distinguished names as the primary keys to
 
   entries in the directory.  Distinguished Names are encoded in
 
   entries in the directory.  Distinguished Names are encoded in
Line 3,489: Line 3,658:
 
   a need to have a user-oriented string representation of
 
   a need to have a user-oriented string representation of
 
   distinguished name.
 
   distinguished name.
 +
 
"An Access Control Approach for Searching and Listing", S.E.
 
"An Access Control Approach for Searching and Listing", S.E.
 
   Hardcastle-Kille, T. Howes, 09/23/1991.
 
   Hardcastle-Kille, T. Howes, 09/23/1991.
 +
 
   This memo defines an extended ACL (Access Control List) mechanism
 
   This memo defines an extended ACL (Access Control List) mechanism
 
   for the OSI Directory.  It is intended to meet strong operational
 
   for the OSI Directory.  It is intended to meet strong operational
Line 3,503: Line 3,674:
 
   beyond, but compatible with, that expected in the 1992 X.500
 
   beyond, but compatible with, that expected in the 1992 X.500
 
   standard.
 
   standard.
 +
 
"Building an Internet Directory using X.500", S. Kille, 01/07/1991.
 
"Building an Internet Directory using X.500", S. Kille, 01/07/1991.
 +
 
   The IETF has established a Working Group on OSI Directory Services.
 
   The IETF has established a Working Group on OSI Directory Services.
 
   A major component of the initial work of this group is to establish
 
   A major component of the initial work of this group is to establish
 
   a technical framework for establishing a Directory Service on the
 
   a technical framework for establishing a Directory Service on the
  
 +
  Internet, making use of the X.500 protocols and services.  This
 +
  document summarizes the strategy established by the Working Group,
 +
  and describes a number of RFCs which will be written in order to
 +
  establish the technical framework.
  
 +
"Directory Requirements for COSINE and Internet Pilots (OSI-DS 18)",
 +
  S.E. Hardcastle-Kille, 07/09/1991.
  
−
 
−
 
−
 
−
 
−
  Internet, making use of the X.500 protocols and services.  This
 
−
  document summarizes the strategy established by the Working Group,
 
−
  and describes a number of RFCs which will be written in order to
 
−
  establish the technical framework.
 
−
"Directory Requirements for COSINE and Internet Pilots (OSI-DS 18)",
 
−
  S.E. Hardcastle-Kille, 07/09/1991.
 
 
   This document specifies operational requirements for DUAs and DSAs
 
   This document specifies operational requirements for DUAs and DSAs
 
   in the Internet and COSINE communities.  This document summarizes
 
   in the Internet and COSINE communities.  This document summarizes
Line 3,526: Line 3,695:
 
   core directory infrastructure. Each application using the directory
 
   core directory infrastructure. Each application using the directory
 
   may impose additional requirements.
 
   may impose additional requirements.
 +
 
"DSA Naming", S.E. Hardcastle-Kille, 01/24/1992.
 
"DSA Naming", S.E. Hardcastle-Kille, 01/24/1992.
 +
 
   This document describes a few problems with DSA Naming as currently
 
   This document describes a few problems with DSA Naming as currently
 
   deployed in pilot exercises, and suggests a new approach.  This
 
   deployed in pilot exercises, and suggests a new approach.  This
Line 3,532: Line 3,703:
 
   which overcomes a number of existing problems, and is an important
 
   which overcomes a number of existing problems, and is an important
 
   component for the next stage in increase of scale.
 
   component for the next stage in increase of scale.
 +
 
"Handling QOS (Quality of service) in the Directory", S.E. Kille,
 
"Handling QOS (Quality of service) in the Directory", S.E. Kille,
 
   08/29/1991.
 
   08/29/1991.
 +
 
   This document describes a mechanism for specifying the Quality of
 
   This document describes a mechanism for specifying the Quality of
 
   Service for DSA Operations and Data in the Internet Pilot Directory
 
   Service for DSA Operations and Data in the Internet Pilot Directory
 
   Service "Building and internet directory using X.500".
 
   Service "Building and internet directory using X.500".
 +
 
"Interim Directory Tree Structure for Network Infrastructure
 
"Interim Directory Tree Structure for Network Infrastructure
 
   Information", Chris Weider, Mark Knopper, Ruth Lang, 06/14/1991.
 
   Information", Chris Weider, Mark Knopper, Ruth Lang, 06/14/1991.
 +
 
   As work progresses on incorporating WHOIS and Network
 
   As work progresses on incorporating WHOIS and Network
 
   Infrastructure information into X.500, we thought it would be
 
   Infrastructure information into X.500, we thought it would be
Line 3,546: Line 3,721:
 
   describes the current structure, the second section the possible
 
   describes the current structure, the second section the possible
 
   expansion of the structure.
 
   expansion of the structure.
 +
 
"Interim Schema for Network Infrastructure Information in X.500 New
 
"Interim Schema for Network Infrastructure Information in X.500 New
 
   name:  Encoding Network Addresses to support operation ov", Chris
 
   name:  Encoding Network Addresses to support operation ov", Chris
 
   Weider, Mark Knopper, 06/14/1991.
 
   Weider, Mark Knopper, 06/14/1991.
 +
 
   As the OSI Directory progresses into an operational structure which
 
   As the OSI Directory progresses into an operational structure which
 
   is being increasingly used as a primary resource for Directory
 
   is being increasingly used as a primary resource for Directory
 
   Information, it was perceived that having the Internet Site
 
   Information, it was perceived that having the Internet Site
−
 
−
 
−
 
−
 
−
 
−
 
  
 
   Contacts and some limited network information in the Directory
 
   Contacts and some limited network information in the Directory
Line 3,563: Line 3,734:
 
   framework for some distributed NIC functions. This paper describes
 
   framework for some distributed NIC functions. This paper describes
 
   the interim schema used to contain this information.
 
   the interim schema used to contain this information.
 +
 
"Naming Guidelines for Directory Pilots", P. Barker, S.E. Kille,
 
"Naming Guidelines for Directory Pilots", P. Barker, S.E. Kille,
 
   01/30/1992.
 
   01/30/1992.
 +
 
   Deployment of a Directory will benefit from following certain
 
   Deployment of a Directory will benefit from following certain
 
   guidelines. This document defines a number of naming guidelines.
 
   guidelines. This document defines a number of naming guidelines.
 
   Alignment to these guidelines will be recommended for national
 
   Alignment to these guidelines will be recommended for national
 
   pilots.
 
   pilots.
 +
 
"OSI NSAP Address Format For Use In The Internet", R Colella, R Callon,
 
"OSI NSAP Address Format For Use In The Internet", R Colella, R Callon,
 
   02/13/1991.
 
   02/13/1991.
 +
 
   The Internet is moving towards a multi-protocol environment that
 
   The Internet is moving towards a multi-protocol environment that
 
   includes OSI. To support OSI, it is necessary to address network
 
   includes OSI. To support OSI, it is necessary to address network
Line 3,579: Line 3,754:
 
   Specific Part of NSAP addresses for use in the Internet that is
 
   Specific Part of NSAP addresses for use in the Internet that is
 
   consistent with these principles.
 
   consistent with these principles.
 +
 
"Representing Public Archives in the Directory", Wengyik Yeong,
 
"Representing Public Archives in the Directory", Wengyik Yeong,
 
   12/04/1991.
 
   12/04/1991.
 +
 
   The proliferation of publicly accessible archives in the Internet
 
   The proliferation of publicly accessible archives in the Internet
 
   has created an ever-widening gap between the fact of the existence
 
   has created an ever-widening gap between the fact of the existence
Line 3,590: Line 3,767:
 
   class of resources, there is a need for these gaps in knowledge to
 
   class of resources, there is a need for these gaps in knowledge to
 
   be bridged.
 
   be bridged.
 +
 
"Schema for Information Resource Description in X.500", Chris Weider,
 
"Schema for Information Resource Description in X.500", Chris Weider,
 
   06/14/1991.
 
   06/14/1991.
 +
 
   The authors are interested in allowing distributed access and
 
   The authors are interested in allowing distributed access and
 
   updating for Information Resource Description information to users
 
   updating for Information Resource Description information to users
Line 3,598: Line 3,777:
 
   are taken from the US-MARC fields, and subfields, with the mapping
 
   are taken from the US-MARC fields, and subfields, with the mapping
 
   described in the text.
 
   described in the text.
−
 
−
 
−
 
−
 
−
 
−
 
−
 
  
 
"Schema for NIC Profile Information in X.500", Chris Weider, Mark
 
"Schema for NIC Profile Information in X.500", Chris Weider, Mark
 
   Knopper, 06/14/1991.
 
   Knopper, 06/14/1991.
 +
 
   The authors of this document, in conjunction with the chairs of the
 
   The authors of this document, in conjunction with the chairs of the
 
   IETF Network Information Services Infrastructure (NISI) group,
 
   IETF Network Information Services Infrastructure (NISI) group,
Line 3,616: Line 3,789:
 
   the Internet and some of its infrastructure.  This document
 
   the Internet and some of its infrastructure.  This document
 
   proposes a set of standard schema for this information.
 
   proposes a set of standard schema for this information.
 +
 
"Using the OSI Directory to Achieve User Friendly Naming", S. Kille,
 
"Using the OSI Directory to Achieve User Friendly Naming", S. Kille,
 
   01/30/1992.
 
   01/30/1992.
 +
 
   The OSI Directory has user friendly naming as a goal.  A simple
 
   The OSI Directory has user friendly naming as a goal.  A simple
 
   minded usage of the directory does not achieve this.  Two aspects
 
   minded usage of the directory does not achieve this.  Two aspects
Line 3,630: Line 3,805:
 
   reference of "A String Representation of Distinguished Name", and
 
   reference of "A String Representation of Distinguished Name", and
 
   it is intended that these specifications are compatible.
 
   it is intended that these specifications are compatible.
 +
 
"Requirements for X.400 Management Domains (MDs) Operating in the Global
 
"Requirements for X.400 Management Domains (MDs) Operating in the Global
 
   Research and Development X.400 Service", R. Hagens, 11/12/1991.
 
   Research and Development X.400 Service", R. Hagens, 11/12/1991.
 +
 
   This  document  specifies  a  set  of  minimal  operational
 
   This  document  specifies  a  set  of  minimal  operational
 
   requirements that  must  be  implemented  by all Management Domains
 
   requirements that  must  be  implemented  by all Management Domains
Line 3,639: Line 3,816:
 
   R&D X.400 Service is defined as all organizations which meet the
 
   R&D X.400 Service is defined as all organizations which meet the
 
   requirements described in this document.
 
   requirements described in this document.
 +
 
"Routing Coordination for X.400 MHS Services within a
 
"Routing Coordination for X.400 MHS Services within a
 
   Multiprotocol/Multinetwork Environment", U. Eppenberger,
 
   Multiprotocol/Multinetwork Environment", U. Eppenberger,
 
   10/25/1992.
 
   10/25/1992.
 +
 
   The X.400 addresses do start to appear on business cards. The
 
   The X.400 addresses do start to appear on business cards. The
 
   different MHS service providers are not well interconnected and
 
   different MHS service providers are not well interconnected and
Line 3,647: Line 3,826:
 
   know where to route all the new addresses. A big number of X.400
 
   know where to route all the new addresses. A big number of X.400
 
   implementations support different lower layer stacks. Taking into
 
   implementations support different lower layer stacks. Taking into
−
 
−
 
−
 
−
 
−
 
−
 
  
 
   account the variety of existing large transport networks, there is
 
   account the variety of existing large transport networks, there is
Line 3,663: Line 3,836:
 
   the gap until an X.500 directory service is ready to store the
 
   the gap until an X.500 directory service is ready to store the
 
   needed connectivity and routing information.
 
   needed connectivity and routing information.
 +
 
                   International Standards Documents
 
                   International Standards Documents
 +
 
International Consultative Committee for Telephone and Telegraph. Open
 
International Consultative Committee for Telephone and Telegraph. Open
 
   Systems Interconnection - The Directory. X.500 Series
 
   Systems Interconnection - The Directory. X.500 Series
 
   Recommendations.  December, 1988.
 
   Recommendations.  December, 1988.
 +
 
   (also published as)
 
   (also published as)
 +
 
ISO/IEC. Information Technology - Open Systems Interconnection - The
 
ISO/IEC. Information Technology - Open Systems Interconnection - The
 
   Directory. International Standard 9594. 1989.
 
   Directory. International Standard 9594. 1989.
 +
 
International Consultative Committee for Telephone and Telegraph. Data
 
International Consultative Committee for Telephone and Telegraph. Data
 
   Communication Networks - Message Handling Systems. X.400 Series
 
   Communication Networks - Message Handling Systems. X.400 Series
 
   Recommendations. Geneva 1985.
 
   Recommendations. Geneva 1985.
 +
 
International Consultative Committee for Telephone and Telegraph. Data
 
International Consultative Committee for Telephone and Telegraph. Data
 
   Communication Networks - Message Handling Systems. X.400 Series
 
   Communication Networks - Message Handling Systems. X.400 Series
 
   Recommendations. Melbourne, 1988.
 
   Recommendations. Melbourne, 1988.
 +
 
                             NIST Documents
 
                             NIST Documents
 
       (National Institute of Standards and Technology Documents)
 
       (National Institute of Standards and Technology Documents)
 +
 
The following documents can be retrieved from the ESnet Information
 
The following documents can be retrieved from the ESnet Information
 
Server in directory [ANONYMOUS.NIST].
 
Server in directory [ANONYMOUS.NIST].
 +
 
Government Open Systems Interconnection Profile (GOSIP) Version 1,
 
Government Open Systems Interconnection Profile (GOSIP) Version 1,
 
   National Institute of Standards and Technology, Federal Information
 
   National Institute of Standards and Technology, Federal Information
 
   Processing Standards Publication #146, August, 1988.
 
   Processing Standards Publication #146, August, 1988.
 +
 
Government Open Systems Interconnection Profile (GOSIP) Version 2,
 
Government Open Systems Interconnection Profile (GOSIP) Version 2,
 
   National Institute of Standards and Technology, October, 1990.
 
   National Institute of Standards and Technology, October, 1990.
 +
 
                             DOE Documents
 
                             DOE Documents
 +
 
The following documents prepared by the DOE GOSIP Migration Working
 
The following documents prepared by the DOE GOSIP Migration Working
 
Group can be retrieved from the ESnet Information Server in directory
 
Group can be retrieved from the ESnet Information Server in directory
 
[ANONYMOUS.DOE-GOSIP].
 
[ANONYMOUS.DOE-GOSIP].
−
 
−
 
−
 
−
 
−
 
−
 
−
 
  
 
U.S. Department of Energy. Government Open Systems Interconnection
 
U.S. Department of Energy. Government Open Systems Interconnection
 
   Profile.  Transition Strategy. DOE GOSIP Document # GW-ST-008.
 
   Profile.  Transition Strategy. DOE GOSIP Document # GW-ST-008.
 
   November, 1990.
 
   November, 1990.
 +
 
U.S. Department of Energy. Government Open Systems Interconnection
 
U.S. Department of Energy. Government Open Systems Interconnection
 
   Profile.  Transition Plan. DOE GOSIP Document # GW_PN_005.
 
   Profile.  Transition Plan. DOE GOSIP Document # GW_PN_005.
 
   November, 1990.
 
   November, 1990.
 +
 
U.S. Department of Energy. Government Open Systems Interconnection
 
U.S. Department of Energy. Government Open Systems Interconnection
 
   Profile.  Procedures and Guidelines. DOE GOSIP Document # GW-PR-
 
   Profile.  Procedures and Guidelines. DOE GOSIP Document # GW-PR-
 
   007. April, 1991.
 
   007. April, 1991.
 +
 
                           IETF Working Groups
 
                           IETF Working Groups
 +
 
Three IETF working groups, OSI X.400, OSI-DS and MHS-DS have been
 
Three IETF working groups, OSI X.400, OSI-DS and MHS-DS have been
 
working in in X.400 and X.500. Minutes of meetings, descriptions of
 
working in in X.400 and X.500. Minutes of meetings, descriptions of
Line 3,713: Line 3,895:
 
Information Server in the directories [ANONYMOUS.IETF.OSIDS],
 
Information Server in the directories [ANONYMOUS.IETF.OSIDS],
 
[ANONYMOUS.IETF.OSIX400] and [ANONYMOUS.IETF.MHSMS].
 
[ANONYMOUS.IETF.OSIX400] and [ANONYMOUS.IETF.MHSMS].
 +
 
                               Others
 
                               Others
 +
 
Marshall T. Rose, Julian P. Onions and Colin J. Robbins. The ISO
 
Marshall T. Rose, Julian P. Onions and Colin J. Robbins. The ISO
 
   Development Environment: User's Manual, 1991.  ISODE Documentation
 
   Development Environment: User's Manual, 1991.  ISODE Documentation
 
   Set.
 
   Set.
 +
 
Marshall T. Rose and Wengyik Yeong.  PSI White Pages Pilot Project:
 
Marshall T. Rose and Wengyik Yeong.  PSI White Pages Pilot Project:
 
   Administrator's Guide, 1991.  ISODE Documentation Set.
 
   Administrator's Guide, 1991.  ISODE Documentation Set.
 +
 
Marshall T. Rose.  The Open Book: A Practical Perspective on Open
 
Marshall T. Rose.  The Open Book: A Practical Perspective on Open
 
   Systems Interconnection. Prentice-hall, 1990. ISBN 0-13-643016-3.
 
   Systems Interconnection. Prentice-hall, 1990. ISBN 0-13-643016-3.
 +
 
Marshall T. Rose.  The Little Black Book: Mail Bonding with OSI
 
Marshall T. Rose.  The Little Black Book: Mail Bonding with OSI
 
   Directory Services. Prentice-hall, 1991. ISBN 0-13-683219-5.
 
   Directory Services. Prentice-hall, 1991. ISBN 0-13-683219-5.
 +
 
Alan Turner and Paul Gjefle, Pacfic Northwest Laboratory.  Performance
 
Alan Turner and Paul Gjefle, Pacfic Northwest Laboratory.  Performance
 
   Analysis of an OSI X.500 (QUIPU) Directory Service Implmentation.
 
   Analysis of an OSI X.500 (QUIPU) Directory Service Implmentation.
 
   1992. Available on nic.es.net in the directory [ANONYMOUS.ESNET-
 
   1992. Available on nic.es.net in the directory [ANONYMOUS.ESNET-
 
   DOC]QUIPU-PERF.PS
 
   DOC]QUIPU-PERF.PS
 +
 
Appendix H:  Task Force Member Information
 
Appendix H:  Task Force Member Information
 +
 
Bob Aiken
 
Bob Aiken
 
   U.S. Department of Energy, Office of Energy Research, Scientific
 
   U.S. Department of Energy, Office of Energy Research, Scientific
 
   Computing Staff (now with National Science Foundation)
 
   Computing Staff (now with National Science Foundation)
 
   Email:  [email protected]
 
   Email:  [email protected]
−
 
−
 
−
 
−
 
−
 
−
 
−
 
  
 
Joe Carlson
 
Joe Carlson
Line 3,744: Line 3,927:
 
   Livermore, California USA
 
   Livermore, California USA
 
   Email:  [email protected]
 
   Email:  [email protected]
 +
 
Les Cottrell
 
Les Cottrell
 
   Stanford Linear Accelerator Center
 
   Stanford Linear Accelerator Center
 
   Menlo Park, California USA
 
   Menlo Park, California USA
 
   Email:  [email protected]
 
   Email:  [email protected]
 +
 
Tim Doody
 
Tim Doody
 
   Fermi National Accelerator Laboratory
 
   Fermi National Accelerator Laboratory
 
   Batavia, Illinois USA
 
   Batavia, Illinois USA
 
   Email:  [email protected]
 
   Email:  [email protected]
 +
 
Tony Genovese  (Contributing Author)
 
Tony Genovese  (Contributing Author)
 
   Lawrence Livermore National Laboratory
 
   Lawrence Livermore National Laboratory
 
   Livermore, California USA
 
   Livermore, California USA
 
   Email:  [email protected]
 
   Email:  [email protected]
 +
 
Arlene Getchell  (Contributing Author)
 
Arlene Getchell  (Contributing Author)
 
   Lawrence Livermore National Laboratory
 
   Lawrence Livermore National Laboratory
 
   Livermore, California USA
 
   Livermore, California USA
 
   Email:  [email protected]
 
   Email:  [email protected]
 +
 
Charles Granieri
 
Charles Granieri
 
   Stanford Linear Accelerator Center
 
   Stanford Linear Accelerator Center
 
   Menlo Park, California USA
 
   Menlo Park, California USA
 
   Email:  [email protected]
 
   Email:  [email protected]
 +
 
Kipp Kippenhan  (Contributing Author)
 
Kipp Kippenhan  (Contributing Author)
 
   Fermi National Accelerator Laboratory
 
   Fermi National Accelerator Laboratory
 
   Batavia, Illinois USA
 
   Batavia, Illinois USA
 
   Email:  [email protected]
 
   Email:  [email protected]
 +
 
Connie Logg
 
Connie Logg
 
   Stanford Linear Accelerator Center
 
   Stanford Linear Accelerator Center
 
   Menlo Park, California USA
 
   Menlo Park, California USA
 
   Email:  [email protected]
 
   Email:  [email protected]
 +
 
Glenn Michel
 
Glenn Michel
 
   Los Alamos National Laboratory
 
   Los Alamos National Laboratory
 
   Los Alamos, New Mexico USA
 
   Los Alamos, New Mexico USA
 
   Email:  [email protected]
 
   Email:  [email protected]
 +
 
Peter Mierswa
 
Peter Mierswa
 
   Digital Equipment Corporation USA
 
   Digital Equipment Corporation USA
−
 
−
 
−
 
−
 
−
 
−
 
−
 
  
 
Jean-Noel Moyne
 
Jean-Noel Moyne
Line 3,790: Line 3,975:
 
   Berkeley, California USA
 
   Berkeley, California USA
 
   Email:  [email protected]
 
   Email:  [email protected]
 +
 
Kevin Oberman  (Contributing Author)
 
Kevin Oberman  (Contributing Author)
 
   Lawrence Livermore National Laboratory
 
   Lawrence Livermore National Laboratory
 
   Livermore, California USA
 
   Livermore, California USA
 
   Email:  [email protected]
 
   Email:  [email protected]
 +
 
Dave Oran
 
Dave Oran
 
   Digital Equipment Corporation USA
 
   Digital Equipment Corporation USA
 +
 
Bob Segrest
 
Bob Segrest
 
   Digital Equipment Corporation USA
 
   Digital Equipment Corporation USA
 +
 
Tim Streater
 
Tim Streater
 
   Stanford Linear Accelerator Center
 
   Stanford Linear Accelerator Center
 
   Menlo Park, California USA
 
   Menlo Park, California USA
 
   Email:  [email protected]
 
   Email:  [email protected]
 +
 
Allen Sturtevant  (Chair, Contributing Author, Document Editor)
 
Allen Sturtevant  (Chair, Contributing Author, Document Editor)
 
   Lawrence Livermore National Laboratory
 
   Lawrence Livermore National Laboratory
 
   Livermore, California USA
 
   Livermore, California USA
 
   Email:  [email protected]
 
   Email:  [email protected]
 +
 
Mike Sullenberger
 
Mike Sullenberger
 
   Stanford Linear Accelerator Center
 
   Stanford Linear Accelerator Center
 
   Menlo Park, California USA
 
   Menlo Park, California USA
 
   Email:  [email protected]
 
   Email:  [email protected]
 +
 
Alan Turner  (Contributing Author)
 
Alan Turner  (Contributing Author)
 
   Pacific Northwest Laboratory
 
   Pacific Northwest Laboratory
 
   Richland, Washington USA
 
   Richland, Washington USA
 
   Email:  [email protected]
 
   Email:  [email protected]
 +
 
Linda Winkler  (Contributing Author)
 
Linda Winkler  (Contributing Author)
 
   Argonne National Laboratory
 
   Argonne National Laboratory
 
   Argonne, Illinois USA
 
   Argonne, Illinois USA
 
   Email:  [email protected]
 
   Email:  [email protected]
 +
 
Russ Wright  (Contributing Author)
 
Russ Wright  (Contributing Author)
 
   Lawrence Berkeley Laboratory
 
   Lawrence Berkeley Laboratory
Line 3,823: Line 4,017:
 
   Email:  [email protected]
 
   Email:  [email protected]
  
 +
Security Considerations
  
−
 
−
 
−
 
−
 
−
 
−
 
−
 
−
 
−
Security Considerations
 
 
Security issues are discussed in sections 2.5.1 and 2.7.5.1 of this
 
Security issues are discussed in sections 2.5.1 and 2.7.5.1 of this
 
memo.
 
memo.
 +
 
Authors' Addresses
 
Authors' Addresses
 +
 
Allen Sturtevant
 
Allen Sturtevant
 
Lawrence Livermore National Laboratory
 
Lawrence Livermore National Laboratory
 
P.O. Box 5509; L-561
 
P.O. Box 5509; L-561
 
Livermore, CA 94551
 
Livermore, CA 94551
 +
 
Phone:  +1 510-422-8266
 
Phone:  +1 510-422-8266
  
Line 3,847: Line 4,036:
 
P.O. Box 5509; L-561
 
P.O. Box 5509; L-561
 
Livermore, CA 94551
 
Livermore, CA 94551
 +
 
Phone:  +1 510-423-2471
 
Phone:  +1 510-423-2471
  
Line 3,854: Line 4,044:
 
P.O. Box 5509; L-561
 
P.O. Box 5509; L-561
 
Livermore, CA 94551
 
Livermore, CA 94551
 +
 
Phone:  +1 510-423-6349
 
Phone:  +1 510-423-6349
  
Line 3,862: Line 4,053:
 
P.O. Box 500
 
P.O. Box 500
 
Batavia, IL 60150
 
Batavia, IL 60150
 +
 
Phone:  +1 708-840-8068
 
Phone:  +1 708-840-8068
  
−
 
−
 
−
 
−
 
−
 
−
 
−
 
−
 
−
 
−
 
−
 
−
 
  
 
Kevin Oberman
 
Kevin Oberman
Line 3,881: Line 4,061:
 
P.O. Box 5509; L-156
 
P.O. Box 5509; L-156
 
Livermore, CA 94551
 
Livermore, CA 94551
 +
 
Phone:  +1 510-422-6955
 
Phone:  +1 510-422-6955
  
Line 3,888: Line 4,069:
 
P.O. Box 999; K7-57
 
P.O. Box 999; K7-57
 
Richland, WA 99352
 
Richland, WA 99352
 +
 
Phone:  +1 509-375-6670
 
Phone:  +1 509-375-6670
  
Line 3,896: Line 4,078:
 
Building 221 B251
 
Building 221 B251
 
Argonne, IL 60439
 
Argonne, IL 60439
 +
 
Phone:  +1 708-252-7236
 
Phone:  +1 708-252-7236
  
Line 3,904: Line 4,087:
 
MS 50B-2258
 
MS 50B-2258
 
Berkeley, CA 94720
 
Berkeley, CA 94720
 +
 
Phone:  +1 510-486-6965
 
Phone:  +1 510-486-6965
  

Latest revision as of 14:10, 16 October 2020

Network Working Group ESCC X.500/X.400 Task Force Request for Comments: 1330 ESnet Site Coordinating Committee (ESCC) 

                                     Energy Sciences Network (ESnet)
                                                            May 1992

         Recommendations for the Phase I Deployment of
               OSI Directory Services (X.500) and
             OSI Message Handling Services (X.400)
                   within the ESnet Community

Status of this Memo

This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.

Overview

The Energy Sciences Network (ESnet) is a nation-wide computer data communications network managed and funded by the United States Department of Energy, Office of Energy Research (U.S. DOE/OER), for the purpose of supporting multiple program, open scientific research. ESnet is intended to facilitate remote access to major Energy Research (ER) scientific facilities, provide needed information dissemination among scientific collaborators throughout all ER programs, and provide widespread access to existing ER supercomputer facilities.

Coordination of ER-wide network-related technical activities over the ESnet backbone is achieved through the ESnet Site Coordinating Committee (ESCC). This committee is comprised of one technical contact person from each backbone site, as well as some members of the ESnet management and networking staff. As the need for new levels of ESnet services arise, the ESCC typically creates task forces to investigate and research issues relating to these new services. Each task force usually results in a whitepaper which makes recommendations to the ESnet community on how these services should be deployed to meet the mission of DOE/OER.

This RFC is a near verbatim copy of the whitepaper produced by the ESnet Site Coordinating Committee's X.500/X.400 Task Force.

3.3.1 Participating in the ESnet Private Management Domain ... 25

3.4.2 Responsibilities in Operating an X.400 Organizational MTA 29

3.5.5 Registering/Listing your PRMD or Organizational MTA with

Appendix D: Sample X.500 Input File and Restricted Character

Appendix F: Local Site Contacts for DOE Naming Authorities ... 70 

           Recommendations for the Phase I Deployment of
                OSI Directory Services (X.500) and
               OSI Message Handling Services (X.400)
                    within the ESnet Community

     ESnet Site Coordinating Committee X.500/X.400 Task Force

                            Version 1.1

                            March 1992

Status of this Document

This document makes recommendations for the Phase I deployment of OSI Directory Services and OSI Message Handling Services within the ESnet Community. This document is available via anonymous FTP on the ESnet Information Server (nic.es.net, 128.55.32.3) in the directory [ANONYMOUS.ESNET-DOC] in the file ESNET-X500-X400-VERSION-1-1.TXT. The distribution of this document is unlimited.

Acknowledgments

The following individuals have participated in and contributed to the ESCC X.500/X.400 Task Force. Several of these individuals have also authored portions of this document. See Appendix H for additional information regarding task force members and contributing authors.

Allen Sturtevant (Chair) Lawrence Livermore National Laboratory Bob Aiken U.S. DOE/OER/SCS (now with NSF) Joe Carlson Lawrence Livermore National Laboratory Les Cottrell Stanford Linear Accelerator Center Tim Doody Fermi National Accelerator Laboratory Tony Genovese Lawrence Livermore National Laboratory Arlene Getchell Lawrence Livermore National Laboratory Charles Granieri Stanford Linear Accelerator Center Kipp Kippenhan Fermi National Accelerator Laboratory Connie Logg Stanford Linear Accelerator Center Glenn Michel Los Alamos National Laboratory Peter Mierswa Digital Equipment Corporation Jean-Noel Moyne Lawrence Berkeley Laboratory Kevin Oberman Lawrence Livermore National Laboratory Dave Oran Digital Equipment Corporation Bob Segrest Digital Equipment Corporation Tim Streater Stanford Linear Accelerator Center Mike Sullenberger Stanford Linear Accelerator Center Alan Turner Pacific Northwest Laboratory Linda Winkler Argonne National Laboratory Russ Wright Lawrence Berkeley Laboratory

Contents

Introduction

Abstract and Introduction

This document recommends an initial approach for the Phase I deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESnet community. It is anticipated that directly connected ESnet backbone sites will participate and follow the suggestions set forth in this document.

Section 7 of the "ESnet Program Plan" (DOE/OER-0486T, dated March 1991) cites the need for further research and investigation in the areas of electronic mail and directory services. The ESCC X.500/X.400 Task Force was created to address this need. Additionally, the task force is addressing the issues of a coordinated, interoperable deployment of OSI Directory Services and OSI Message Handling within the entire ESnet community. Since only a small subset of this community is actively pursuing these avenues, considerable effort must be made to establish the necessary "base" to build upon. If directly connected ESnet sites participate in these services, a consistent transition path will be ensured and the services provided will be mutually valuable and useful.

X.500 and X.400 are continuously evolving standards, and are typically updated every four years. U.S. GOSIP (Government OSI Profile) Requirements are updated to define additional functionality as needed by the U.S. Federal Government, usually every two years. As the X.500 and X.400 standards evolve and U.S. GOSIP Requirements are extended, consideration must be given as to the effect this may have on these existing services in the ESnet community. At these cross-roads, or when a sizeable increase in service functionality is desired, another "phase of deployment" may be in order. In this sense, there isn't a specific "final phase" goal, but rather several new releases (updates) to the level of existing services.

Structure of this Document

X.500 is presented first. The issues of DSA (Directory Service Agent) deployment, DSA registration, naming schema, involvement in the PSI White Pages Pilot Project, recommended object classes, recommended attribute types, information security, search optimization, user friendly naming and update frequency are addressed.

In the area of X.400, issues relating to MTA (Message Transfer Agent) deployment, ESnet X.400 well-known entry points, ESnet backbone site X.400 well-known entry points, MTA registration, naming hierarchy, PRMD peering, bidirectional X.400-SMTP relaying and

private/commercial X.400 routing are discussed.

Finally, the issues in name registration with ANSI (American National Standards Institute), GSA (General Services Administration) and the U.S. Department of Commerce, Patent and Trademark Office (PTO) are discussed.

X.500 - OSI Directory Services

Brief Tutorial

X.500 is a CCITT/ISO standard which defines a global solution for the distribution and retrieval of information (directory service). The X.500 standard includes the following characteristics: decentralized management, powerful searching capabilities, a single global namespace, and a structured framework for the storage of information. The 1988 version of the X.500 standard specifies four models to define the Directory Service: the Information Model, the Functional Model, the Organizational Model and the Security Model. As is the nature of International standards, work continues on the 1992 X.500 standard agreements.

The Information Model specifies how information is defined in the directory. The Directory holds information objects, which contain information about "interesting" objects in the real-world. These objects are modeled as entries in an information base, the Directory Information Base (DIB). Each entry contains information about one object: ie, a person, a network, or an organization. An entry is constructed from a set of attributes each of which holds a single piece of information about the object. For example, to build an entry for a person the attributes might include "surname", "telephoneNumber", "postalAddress", "rfc822Mailbox" (SMTP mail address), "mhsORAddresses" (X.400 mail address) and "facsimileTelephoneNumber". Each attribute has an attribute syntax which describes the data that the attribute contains, for example, an alphanumeric string or photo data. The OSI Directory is extensible in that it defines several common types of objects and attributes and allows the definition of new ones as new applications are developed that make use of the Directory. Directory entries are arranged in a hierarchical structure, the Directory Information Tree (DIT). It is this structure which is used to uniquely name entries. The name of an entry is its Distinguished Name (DN). It is formed by taking the DN of the parent's entry, and adding the the Relative Distinguished Name (RDN) of the entry. Along the path, the RDNs are collected, each naming an arc in the path. Therefore, a DN for an entry is built by tracing the path from the root of the DIT to the entry.

The Functional Model defines how the information is stored in the

directory, and how users access the information. There are two components of this model: the Directory User Agent (DUA), an application-process which interacts with the Directory on behalf of the user, and the Directory System Agent (DSA), which holds a particular subset of the Directory Information Tree and provides an access point to the Directory for a DUA.

The Organizational Model of the OSI Directory describes the service in terms of the policy defined between entities and the information they hold. The model defines how portions of the DIT map onto DSAs. A Directory Management Domain (DMD) consists of one or more DSAs, which collectively hold and manage a portion of the DIT.

The Security Model defines two types of security for Directory data: Simple Authentication (using passwords) and Strong Authentication (using cryptographic keys). Authentication techniques are invoked when a user or process attempts a Directory operation through a DUA.

Participation in the PSI White Pages Pilot Project

The PSI White Pages Pilot Project is currently the most well- established X.500 pilot project within the United States. For the country=US portion of the DIT, PSI currently has over 80 organization names registered. Of these, several are ESnet-related.

The PSI White Pages Pilot Project is also connected to the Pilot International Directory Service, PARADISE. This pilot project interconnects X.500 Directory Services between Australia, Austria, Belgium, Canada, Denmark, Finland, France, Germany, Greece, Iceland, Ireland, Israel, Italy, Japan, Luxembourg, Netherlands, New Zealand, Norway, Portugal, Spain, Sweden, Switzerland, United Kingdom and Yugoslavia. The combined totals for all of these countries (including the United States) as of December 1991 are: 

                   DSAs:                     301
                   Organizations:          2,132
                   White Pages Entries:  581,104

Considering the large degree of national, and international, connectivity within the PSI White Pages Pilot Project, it is recommended that directly connected ESnet backbone sites join this pilot project.

Recommended X.500 Implementation

Interoperability testing has not been performed on most X.500 implementations. Further, some X.500 functions are not mature standards and are often added by implementors as noninteroperable

extensions.

To ensure interoperability for the entire ESnet community, the University College London's publicly available X.500 implementation (QUIPU) is recommended. This product is known to run on several UNIX-derivative platforms, operates over CLNS and RFC-1006 (with RFC-1006 being the currently recommended stack), and is currently in wide-spread use around the United States and Europe, including several ESnet backbone sites.

Appendix C contains information on how to obtain QUIPU.

A later phase deployment of X.500 services within the ESnet community will recommend products (either commercial or public domain) which pass conformance and interoperability tests.

Naming Structure

As participants in the PSI White Pages Pilot Project, ESnet backbone sites will align with the naming structure used by the Pilot. This structure is based upon a naming scheme for the US portion of the DIT developed by the North American Directory Forum (NADF) and documented in RFC-1255. Using this scheme, an organization with national standing would be listed directly under the US node in the global DIT. Organizations chartered by the U.S. Congress as well as organizations who have alphanumeric nameforms registered with ANSI are said to have national standing. Therefore, a backbone site which is a national laboratory would be listed under country=US: 

          @c=US@o=Lawrence Livermore National Laboratory

As would a site with an ANSI-registered organization name: 

       @c=US@o=National Energy Research Supercomputer Center

A university would be listed below the state in which it is located: 

            @c=US@st=Florida@o=Florida State University

And a commercial entity would be listed under the city or state in which it is doing business, or "Doing Business As", depending upon where its DBA is registered: 

               @c=US@st=California@o=General Atomics
                               (or)
         @c=US@st=California@l=San Diego@o=General Atomics

A list of the current ESnet backbone sites, and their locations, is

provided in Appendix E.

Directly connected ESnet backbone sites will be responsible for administering objects which reside below their respective portions of the DIT. Essentially, they must provide their own "Name Registration Authority". Although this may appear as an arduous task, it is nothing more than the establishment of a procedure for naming, which ensures that duplicate entries do not occur at the same level within a sub-tree of the DIT. For example, the Name Registration Authority for MIT could create an Organizational Unit named "Computer Science". This would appear in the DIT as: 

         @c=US@st=Massachusetts@o=MIT@ou=Computer Science

Similarly, all other names created under the "@c=US@st=Massachusetts@o=MIT" portion of the DIT would be administered by the same MIT Name Registration Authority. This ensures that every Organizational Unit under "@c=US@st=Massachusetts@o=MIT" is unique. By default, each ESnet Site Coordinator is assumed to be the Name Registration Official for their respective site. If an ESnet Site Coordinator does not wish to act in this capacity, they may designate another individual, at their site, as the Name Registration Official.

Implications of the Adoption of RFC-1255 by PSI

The North American Directory Forum (NADF) is comprised of commercial vendors positioning themselves to offer commercial X.500 Directory Services. The NADF has produced several documents since its formation. The ones of notable interest are those which define the structure and naming rules for the commercially operated DIT under country=US. Specifically, for an Organization to exist directly under c=US, it must be an organization with national-standing. From pages 12-13 of RFC-1255, national-standing is defined in the following way: 

  "An organization is said to have national-standing if it is
  chartered (created and named) by the U.S. Congress.  An example
  of such an organization might be a national laboratory.  There
  is no other entity which is empowered by government to confer
  national-standing on organizations.  However, ANSI maintains an
  alphanumeric nameform registration of organizations, and this
  will be used as the public directory service basis for
  conferring national-standing on private organizations."

Thus, it appears that National Laboratories (e.g. LBL, LLNL) are considered organizations with national-standing. However, those ESnet backbone sites which are not National Laboratories may wish to

register with ANSI to have their organization list directly under c=US, but only if this is what they desire. It is important to note that NADF is not a registration authority, but a group of service providers defining a set of rules for information sharing and mutual interoperability in a commercial environment.

For further information on registering with ANSI, GSA or the U.S. Patent and Trademark office, refer to Section 4 of this document. For more information on PSI, refer to Appendix A.

Universities and Commercial Entities

Several of the ESnet backbone sites are not National Laboratories (e.g. CIT, FSU, GA, ISU, MIT, NYU, UCLA and UTA). Typically, at these sites, a small collection of researchers are involved in performing DOE/OER funded research. Thus, this set of researchers at a given site may not adequately represent the total X.500 community at their facility. Additionally, ESnet Site Coordinators at these facilities may not be authorized to act as the Name Registration Official for their site. So the question is, how do these sites participate in the recommended Phase I deployment of ESnet X.500 services. There are two possible solutions for this dilemma:

1. If the site is not currently operating an X.500 DSA, the ESnet 

   Site Coordinator may be able to establish and administer a
   DSA to master the DOE/OER portion of the site's local DIT,
   e.g. "@c=US@st=<st>@o=<site>@ou=Physics".  Before attempting
   this action, it would be prudent for the Site Coordinator to
   notify or seek approval from some responsible entity.  At such
   time that the site wishes to manage its own organization
   within the X.500 DIT, the ESnet Site Coordinator would have to
   make arrangements to put option 2 into effect.

2. If the site is currently operating an X.500 DSA, the ESnet 

   Site Coordinator may be able to work out an agreement with the
   current DSA administrator to administer a portion of the
   site's local DIT which would represent the DOE/OER community
   at that site.  For example, if the site were already
   administering the organization "@c=US@st=
   Massachusetts@o=Massachusetts Institute of Technology", the
   ESnet Site Coordinator might then be able to administer the
   organizational unit "@c=US@st=Massachusetts@o=Massachusetts
   Institute of Technology@ ou=Physics".

Naming Structure Below the o=<site> Level

The structure of the subtree below the organization's node in the DIT is a matter for the local organization to decide. A site's DSA

manager will probably want to enlist input from others within the organization before deciding how to structure the local DIT.

Some organizations currently participating in the Pilot have established a simple structure, choosing to limit the number of organizational units and levels of hierarchy. Often this is done in order to optimize search performance. This approach has the added benefit of insulating the local DIT from administrative restructuring within the organization. Others have chosen to closely model their organization's departmental structure. Often this approach seems more natural and can enhance the information obtained from browsing the Directory.

Below are experiences from current DSA managers, describing the way they structured their local DIT and the reasons for doing so. A site may find this information helpful in determining how to structure their local DIT. Ultimately this decision will depend upon the needs of the local organization and expectations of Directory usage.

Valdis Kletnieks of the Virginia Polytechnic Institute: 

  "For Virginia Tech, it turned out to be a reasonably
  straightforward process.  Basically, the University is
  organized on a College/Department basis.  We decided to model
  that "real" structure in the DIT for two major reasons:

  "(a) It duplicates the way we do business, so interfacing the
  X.500 directory with the "real world" is easier.

  "(b) With 600+ departmental units and 11,000+ people (to be
  30,000+ once we add students), a "zero" (everybody at top) or
  "one" deep (600 departments at top) arrangement just didn't
  hack it - it was deemed necessary that you be able to do a
  some 120 or 140 county office entries under the Extension
  service, it's a BIT unwieldy there).  However, with some 20
  college-level entries at the top, and the "average" college
  having 30 departments, and the "average" department being from
  10 to 40 people, it works out pretty well."

Jeff Tannehill of Duke University: 

  "Our DIT is flat.  We get the entire database of people at Duke
  from Tel-Com and just put everyone directly under "O=Duke
  University".

  "Actually, there is an exception, when the DSA was first set up
  and we had not received a database yet, I configured the DIT to
  include "OU=Computer Science", under which myself and one other

  System Administrator have entries.  Upon getting the database
  for everyone else I decided not to attempt to separate the
  people in the database into multiple ou's."

Joe Carlson of Lawrence Livermore National Laboratory: 

  "We tried both flat (actually all under the same OU) and
  splitting based on internal department name and ended up with
  flat.  Our primary reason was load and search times, which were
  2-3 times faster for flat organization."

Paul Mauvais of Portland State University: 

  "We originally set up our DIT by simply loading our campus
  phone book into one level down from the top (e.g. OU=Faculty
  and Staff, OU=Students, OU=Computing Services).

  "I'd love to have an easy way to convert our flat faculty and
  staff area into departments and colleges, but the time to
  convert the data into the separate OU's is probably more than I
  have right now."

Mohamed Ellozy of Dana-Farber Cancer Institute: 

  "Here we have a phone database that includes department, so we
  got the ou's with no effort.  We thus never went the flat space
  way."

Dan Moline of TRW: 

  "Well - we're still in the process of defining our DIT.  TRW
  comes under the international companies DBA.  Our part under
  the PSI White Pages Pilot defines the DIT for our space and
  defense organization here in Redondo Beach (however, I
  organized the structure to adhere to TRW corporate).  We input
  from our manpower DB for our S&D personnel.  We're trying to
  get corporate's DB for possible input.

  "However, arranging your DIT by organizations (at least for
  corps) presents a problem; things are always being reorganized!
  We were DSO now we're SSO!!!  We still have some of our old
  domain name for DNS tied to organizations that have not existed
  for years!

  "So we are currently redesigning our DIT to try to fit NADF 175
  (something more geographically).  Our reasoning was that
  organizations may change but buildings and localities do not."

Ruth Lang of SRI: 

  "There has been no SRI-wide policy or decision to participate
  in the PSI White Pages Pilot.  @c=US@O=SRI International
  supports the information for one OU only (i.e., a local policy
  and decision).  In order to not give the false impression that
  all SRI information was contained under this O=SRI
  International, I used OU=Network Information Systems Center.
  If I were to structure the DIT for all of SRI, I'm sure that my
  thinking would yield a much different structure."

Russ Wright of Lawrence Berkeley Laboratory: 

  "Since we don't have much organizational information in current
  staff database, I have to stick to a fairly flat structure.  I
  have two OUs.  One is for permanent staff, the other is for
  guests (there is a flag in our database that is set for
  guests).

  "I may add an additional level of OUs to our current structure.
  The top level would contain different 'types' of information.
  For example, one OU may be 'Personnel', another may be called
  publications).  Staff and Guests would reside under the
  Personnel OU."

Peter Yee of NASA Ames: 

  "I broke up my DIT at the NASA Center level.  NASA is made of
  nearly 20 Centers and Facilities.  The decision to break up at
  this level was driven by several factors:

  "1.  Control of the local portion of the DIT should reside with
  the Center in question, particularly since the Center probably
  supplies the data in question and controls the matching DSA.

  "2.  Each Center ranges in size from 1,000 to 16,000 persons.
  This seems to be the range that works well on moderate sized
  UNIX servers.  Smaller would be a waste, larger would require
  too much memory.

  "3.  Representatives from several Centers have contacted me
  asking if they could run their own DSAs so that they can
  experiment with X.500.  Thus the relevant DSA needs to be under
  their control."

Information Stored in X.500

The Phase I deployment of X.500 should be limited to "white pages"-

type information about people. Other types of objects can be added in later Phases, or added dynamically as the need arises.

To make X.500 truly useful to the ESnet community as a White Pages service, it is recommended that the following minimum information should be stored in the X.500 database:

Information ASN.1 Attribute Type Example

-------------------- -------

Locator Info commonName Allen Sturtevant 

             surname                   Sturtevant
             postalAddress             LLNL
                                       P.O. Box 5509, L-561
                                       Livermore, CA 94551
             telephoneNumber           +1 510 422 8266
             facsimileTelephoneNumber  +1 510 422 0435

E-Mail Info rfc822Mailbox [email protected] 

             mhsORAddresses            /PN=Allen Sturtevant/O=NERSC/
                                         /PRMD=ESnet/ADMD= /C=US/
             otherMailbox              DECnet:  ESNIC::APS

The above list of attributes comprises a minimum set which is recommended for a person's entry. However, you may chose to omit some attributes for reasons of privacy or legality. Note that the X.500 standard requires that the surname and commonName attributes be present. If an individual's phone number and/or address cannot be provided, they should be replaced by the site's "Information Phone Number" and postal address to allow some means of contacting the person.

Information Security

It is understood that placing this type of information in X.500 is equivalent to putting the "Company Phone Book" on-line in the Internet. Different sites may treat this information differently. Some may view it as confidential, while others may view this data as open to the public. In any case, it was recommended that ESnet sites discuss the implications with their respective legal departments before actually making their information openly available. There currently exists minimal access control in several X.500 implementations.

Accessing the X.500 Directory Service

The PSI White Pages Pilot Project software provides numerous interfaces to the information in the X.500 Directory. Non- interactive access mechanisms (e.g. WHOIS, FINGER and Electronic

Mail) make use of capabilities or services which already reside on many workstations and hosts. Such hosts could immediately take advantage of the X.500 service with no additional software or reconfiguration needed. However, since these methods are non- interactive, they only provide a way to search for and read information in the Directory but no way to modify information.

Directory Service via WHOIS

The Pilot Project software allows you to configure the X.500 Directory service to be made available via a network port offering an emulation of the SRI-NIC WHOIS service. UNIX-based hosts and VMS hosts running Multinet typically come configured with the WHOIS service. Users at their workstations would then be able to issue a simple WHOIS command to a known host running a DSA to retrieve information about colleagues at their site or at other ESnet sites. For example, the command: 

  whois -h wp.lbl.gov wright

will return information about Russ Wright at Lawrence Berkeley Lab. It is recommended that all sites which bring up such a service, should provide an alias name for the host running their DSA of the form <wp.site.domain> for consistency within the ESnet community.

Directory Service via Electronic Mail

The Pilot Project software also allows the X.500 Directory service to be made available via electronic mail. A user who sends an electronic mail message to a known host running a DSA containing a WHOIS-like command on the subject line, would then receive a return mail message containing the results of their query.

Directory Service via FINGER

The X.500 Directory service could also be made available via the FINGER service. Although this access method does not come with the PSI Pilot Project software, several sites have already implemented a FINGER interface to the X.500 Directory. For ease of use and consistency, a single FINGER interface should be selected, then individual implementations within the ESnet community should conform to this interface.

Directory Service via Specialized Applications

Many X.500 Directory User Agents (DUAs) are widely available. Some of these come with the PSI Pilot Project software. Other DUAs, which have been developed by third parties to fit into the pilot software,

are publicly available. These user agents support interactive access to the X.500 Directory allowing browsing, searching, listing and modifying data in the Directory. However, in most cases, use of these DUAs requires the Pilot Project software be installed on the host system. Only a few of these DUAs and their capabilities are described below.

o DISH - A User Agent which provides a textual interface to the 

  X.500 Directory.  It gives full access to all elements of the
  Directory Access Protocol (DAP) and as such may be complex for
  novice users.  DISH is most useful to the DSA administrator.

o FRED - A User Agent which has been optimized for "white pages" 

  types of queries.  The FRED program is meant to be similar to
  the WHOIS network service.  FRED supports reading, searching,
  and modifying information in the X.500 Directory.

o POD - An X-windows based User Agent intended for novice users. 

  POD relies heavily on the concept of the user "navigating"
  around the DIT.  Pod supports reading and searching.  There are
  no facilities to add entries or to modify the RDNs of entries,
  though most other entry modifications are allowed.

Directory Service from PCs and MACs

Smaller workstations and personal computers lack the computing power or necessary software to implement a full OSI protocol stack. As a consequence, several "light-weight" protocols have been developed whereby the DAP runs on a capable workstation and exports a simpler interface to other end-systems. One such "light weight" protocol, the Directory Assistance Service (DAS), is incorporated in the PSI Pilot Project software. Another "light weight" protocol, DIXIE, was developed at the University of Michigan. Publicly available User Agents for both the MAC and PC have been developed using the DA- service and the DIXIE protocol. So long as you have the Pilot Project software running on one host, you can provide these User Agents on many end-systems without having to install the Pilot software on all those end-systems.

For further information about available Directory User Agents, see RFC-1292, "Catalog of Available X.500 Implementations".

Services Provided by ESnet

Currently, there are several ESnet backbone sites which are operating their own DSAs within the PSI White Pages Pilot Project. It is anticipated that directly connected ESnet backbone sites will eventually install and operate their own X.500 DSAs. In the interim,

ESnet will provide complete support for ESnet backbone sites which presently do not have the time, expertise or equipment to establish X.500 services. The mechanism for doing this is described in Section 2.7.5 below. Additionally, ESnet will provide a variety of services in support of the entire X.500 community. These are also described in the following sections.

X.500 Operations Mailing List

ESnet maintains a mailing list for the discussion of relevant X.500 topics. This mailing list provides a means for sharing information, experiences, and expertise about X.500 in the ESnet community. New sites joining the ESnet X.500 community will be announced on the mailing list. New DSA administrators will be able to solicit help from more experienced administrators. When a site brings up a new X.500 DSA, the DSA manager should notify the ESnet DSA manager so as to ensure they are promptly added to the mailing list. 

  General discussion:  [email protected]
  To subscribe:        [email protected]

Accessing the X.500 Directory

ESnet has made the X.500 service openly available to the entire ESnet community via each of the access methods described in Section 2.6 above. Host WP.ES.NET provides TELNET access, FINGER and WHOIS emulations, querying via electronic mail, as well as remote access via light-weight protocols. By making these services widely available, we hope to acquaint more users with the features and capabilities of X.500.

To try out some of the X.500 User Agents, simply TELNET to WP.ES.NET and login as user "fred"; no password is required. You have the choice of running the Fred or Pod User Agents. Fred provides a command line interface while Pod provides an X-windows based interface. You can browse through the global X.500 DIT, search for persons in various organizations, and even modify your own entry if you have one.

Host WP.ES.NET also provides access to the X.500 Directory via emulations of the FINGER and WHOIS utilities. These interfaces support a user-friendly-naming (UFN) scheme that simplifies the syntax necessary to search for persons in other organizations. The following WHOIS command lines illustrate searching for persons at various ESnet sites, utilizing the UFN syntax (similar FINGER command lines could also be constructed): 

  whois -h wp.es.net leighton,nersc
  whois -h wp.es.net servey,doe
  whois -h wp.es.net logg,slac
  whois -h wp.es.net "russ wright",lbl

For further information about User Friendly Naming, see Steve Hardcastle-Kille's working document titled, "Using the OSI Directory to Achieve User Friendly Naming".

Backbone Site Aliases

As ESnet backbone sites join the X.500 pilot, their organizations' entries will be placed in various parts of the DIT. For example, National Laboratories will be placed directly under the c=US portion of the DIT, while universities and commercial entities will most likely be placed under localities, such as states or cities.

In order to facilitate searching for the ESnet community as a whole, ESnet backbone sites will also be listed as organizational units under the node "@c=US@o=Energy Sciences Network". These entries will actually be aliases which point to the site's "real" organizational entry. Therefore, ESnet backbone sites will be listed in two different places in the DIT and one could search for them in either location.

Multiprotocol Stack Support

OSI applications currently run over many different transport/network protocols, a factor which hinders communication between OSI end nodes. In order to facilitate communication, the ISODE may be configured at compile time to support any combination of the following stacks: 

  RFC-1006 over TCP/IP
  TP0      over X.25
  TP0      over X.25 (84)
  TP0      over the TP0-bridge
  TP4      over CLNP

Within the ESnet community, the stacks of interest are RFC-1006 over TCP/IP, TP4 over CLNP, and TP0 over X.25. If a backbone site's DSA is not running over all three of these stacks, it may eventually receive referrals to a DSA that it can not connect to directly, so the operation can not proceed. Since the ESnet DSAs will be configured to operate over all of the "stacks of interest," they can serve as relay DSAs between site DSAs that do not have direct connectivity. The site's DSA manager will need to contact the ESnet DSA manager to arrange for this relaying to occur. Backbone sites

will be encouraged to eventually provide as many of the three stacks of interest as possible.

Managing a Site's X.500 Information

For sites which do not initially wish to operate their own DSA, ESnet's DSA will master their site's portion of the DIT, enabling the site to join the PSI Pilot Project and the ESnet X.500 community. In order to accomplish this, the site must provide the ESnet DSA manager with information about the people to be included in the X.500 Directory. This information can usually be obtained from your Site's Personnel Database.

ESnet will only maintain a limited amount of information on behalf of each person to be represented in the Directory. The attribute types listed in the table in Section 2.5 show the maximum amount of information which the ESnet DSA will support for a person's entry in the Directory. This set of attribute types is a small subset of the attribute types offered by the PSI Pilot Project software. Therefore, if a site wishes to include additional attribute types, they should consider installing and operating their own DSA.

The format of the information to be provided to the ESnet DSA manager is as follows: the data should be contained in a flat, ASCII text file, one record (line) per person, with a specified delimiter separating the fields of the record. More detailed information and a sample of a site-supplied data file can be found in Appendix D.

Open Availability of Site Information

Although the PSI Pilot Project allows you to control who may access Directory objects and their attributes, any information you provide about persons at your site to be stored in the ESnet DSA will be considered world readable. This policy is necessary in order to minimize the administrative cost of managing potentially many organizational objects within the ESnet DSA. If your site decides that it does not wish to have certain information about its employees publicly known (e.g. work telephone number) then you should not provide this information to the ESnet DSA manager or you should consider installing and administering your own DSA.

Access Methods for Local Users

Backbone sites which choose the option of having the ESnet DSA master their organization's X.500 information should make the availability of the X.500 service known to their local users. All of the methods described in Section 2.7.2 are available for use, but none of these methods will assume the query is relative to the local site.

To facilitate querying relative to the local environment, the site will need to make one host available to run the emulation of the FINGER service. Although the resulting query will ultimately be directed to the remote ESnet DSA, the search will appear to be local to the users at that site. For example, a user on a workstation at site XYZ could type the following, omitting their local domain name as this is implied: 

  finger jones@wp

This will retrieve information about user Jones at site XYZ (wp is the name or alias of a host at site XYZ, i.e. wp.XYZ.GOV). The site coordinator will need to contact the ESnet DSA manager to arrange the set up for this service.

Limitations of Using ESnet Services

Since the ESnet DSA will potentially be mastering information on behalf of numerous backbone sites, limits will need to be placed on the volume of site information stored in the ESnet DSAs. These are enforced to ensure DSA responsiveness, as well as to reduce administrative maintenance. The limits are: 

             Item                       Maximum Limit
             ----                       -------------
             X.500 Organizations                    1
             Organizational Units                  50
             Organizational Unit Depth              3
             Object Entries                     5,000
             Update Frequency                 1 Month
             Aliases                              n/a
             Object/Attribute Access Control      n/a

One week before each monthly update cycle, a message will be sent on the [email protected] mailer to remind the sites that an update cycle is approaching. If no changes are required to the site information, the reminder message can be ignored and the existing version of this information will be used. If the information is to be updated, a complete replacement of all information must be supplied to the ESnet DSA manager before the next update cycle. More detailed information and a sample of a site-supplied data file can be found in Appendix D.

ESnet Running a Level-0 DSA for c=US

For ESnet to provide high quality X.500 services to the ESnet community, the ESnet DSAs must operate as Level-0 (first level) DSAs. It is currently planned that these DSAs will act as slave, Level-0 DSAs to PSI's master, Level-0 DSAs. Once the ESnet DSAs are in

production service, it is recommended that directly connected ESnet backbone sites operating their own X.500 DSAs configure them with one of the ESnet DSAs as their parent DSA. This provides several advantages to the ESnet community:

1. The ESnet DSAs will be monitored by the NERSC's 24-hour 

   Operations Staff.  Additionally, ESnet plans to deploy two
   (2) DSAs in geographically disperse locations to ensure
   reliability and availability.

2. All queries to Level-0 DSAs remain within the ESnet high-speed 

   backbone.

3. If network connectivity is lost to all external Level-0 DSAs, 

   X.500 Level-0 connectivity will still exist within the ESnet
   backbone.

X.500 Registration Requirements

X.500 organization names must be nationally unique if they appear directly below the c=US level in the DIT structure. Nationally unique names must be registered through an appropriate registration authority, i.e., one which grants nationally unique names.

X.500 organizational unit names need to be unique relative to the node directly superior to them in the DIT. Registration of these names should be conducted through the "owner" of the superior node.

The registration of X.500 names below the organization level are usually a local matter. However, all siblings under a given node in the DIT must have unique RDNs.

See Section 4 for a more complete description of OSI registration issues and procedures.

2.10. Future X.500 Issues to be Considered

2.10.1. ADDMDS Interoperating with PRDMDS

This is a problem which currently does not have an answer. The issue of Administrative Directory Management Domains (ADDMDs) interacting with Private Directory Management Domains (PRDMDs) is just beginning to be investigated by several groups interested in solving this problem.

2.10.2. X.400 Interaction with X.500

The current level of understanding is that X.400 can benefit from the

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.

X.400 - OSI Message Handling Services

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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:  [email protected]
  To subscribe:        [email protected]

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.

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.

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.

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)

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.

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.

Future X.400 Issues to be Considered

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.

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.

X.400 Interaction with X.500

This is discussed in Section 2.10.2.

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.

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.

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.

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.

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.

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

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:  [email protected]

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.

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.

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.

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.

Future Name Registration Issues to be Considered

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:  [email protected]
  To Subscribe:        [email protected]

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:  [email protected]
  To Subscribe:        [email protected]

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:  [email protected]
  To Subscribe:        [email protected]

                         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: 

  [email protected]

                   PSI White Pages Pilot Project

The White Pages Pilot Project is the first production-quality field test of the OSI Directory (X.500). The pilot currently has a few hundred organizations (more each month) and is based on OSI TP4 over TCP/IP (RFC-1006).

Anonymous FTP site address: (Most X.500 pilot project software is 

  uu.psi.com                 here as well as more information)

             ANSI ASC X3T5.4 (Directory Ad Hoc Group)

The American National Standards Institute (ANSI) Accredited Standards Committee (ASC) X3T5.4. This group reviews the Proposed Draft Amendments (PDAMs) for extensions to the International Consultative Committee for Telegraphy and Telephony (CCITT) X.500 Recommendations/International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) 9594.

Appendix B: Current Activities in X.400

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

            IETF OSIX400 (IETF OSI X.400 Working Group)

The IETF OSI X.400 Working Group is chartered to identify and provide solutions for problems encountered when operating X.400 in a dual protocol internet. This charter includes pure X.400 operational issues as well as X.400 <-> RFC 822 gateway (ala RFC 987) issues.

Mailing list address: 

  General Discussion:  [email protected]
  To Subscribe:        [email protected]

        IETF X400OPS (IETF X.400 Operations Working Group)

X.400 management domains are being deployed today on the Internet. There is a need for coordination of the various efforts to insure that they can interoperate and collectively provide an Internet-wide X.400 message transfer service connected to the existing Internet mail service. The overall goal of this group is to insure interoperability between Internet X.400 management domains and to the existing Internet mail service. The specific task of this group is to produce a document that specifies the requirements and conventions of operational Internet PRMDs.

Mailing list address: 

  General Discussion:  [email protected]
  To Subscribe:        [email protected]

 IETF MHS-DS (IETF Message Handling Services - Directory Services)

The MHS-DS Group works on issues relating to Message Handling Service use of Directory Services. The Message Handling Services are primarily X.400, but issues relating to RFC 822 and RFC 822 interworking, in as far as use of the Directory is concerned, are in the scope of the Group. Directory Services means the services based on X.500 as specified by the OSI-DS group (RFCs 1274, 1275, 1276, 1277, 1278, 1297). The major aim of this group is to define a set of specifications to enable effective large scale deployment of X.400. While this Group is not directly concerned with piloting, the focus is practical, and implementations of this work by members of the Group is expected.

Mailing list address: 

  General Discussion:  [email protected]
  To Subscribe:        [email protected]

Anonymous FTP site address: (e-mail archive is here) 

  mercury.udev.cdc.com

                     XNREN X.400 Pilot Project

The Internet X.400 Project at the University of Wisconsin is funded by NSF. We are working on two main areas:

1. Supporting the operational use of X.400.

2. Working with others to define organizational procedures 

   necessary to operate X.400 on a large scale in the Internet.

To support the use of X.400, we are operating a PRMD, assisting sites in running PP or the Wisconsin Argo X.400 software packages, and

running an X.400 Message Transfer Agent (MTA) which is connected to U.S. and international MTAs using RFC1006/TCP/IP. Internet sites are invited to join our PRMD or establish X.400 connections with us. The organizational work is being done jointly by IETF working groups and RARE Working Group 1.

Mailing list address: 

  General Discussion:  [email protected]

    RARE WG1 (RARE Working Group 1 - Message Handling Systems)

RARE (Reseaux Associes pour la Recherche Europeenne) Working Group 1, Message Handling Systems, creates and promotes a European infrastructure for a message handling service within the European research community, with connections to the global environment. Membership of the Working Group is by nomination from the national networking organizations, together with a number of invited experts. 

  CCITT SG-D MHS-MD (CCITT Study Group D, MHS Management Domains)

This group initially pursues the development of the rules for registering MHS management Domain names within the US. This group also pursues developing a set of voluntary agreements for North American operators of these management domains which will allow the US to uphold its Telecommunications treaty obligations while the industry maintains e-mail as an Information Processing service. The specific aspect of the treaty that is immediate concern to this group is that subscribers of MHS services in other countries, especially those countries who treat MHS as a Telecommunications service, must be able to reach MHS users in this country regardless of how their message enters the US and regardless of how many domains are involved in the transfer of the message to the intended recipient.

The US State Department presently considers MHS (e-mail) as an Information Processing service. Some other countries consider any MHS (e-mail) service to be a Telecommunications service and hence, CCITT treaty obligations apply. 

          NIST/GSA Interagency X.400 Connectivity Project

The goal of this project is to assist the members of the Federal Information Resource Management Policy Council (FIRMPoC) in establishing electronic mail connectivity based on X.400. The outcome of this project is to continue, as the National Institute of Standards and Technology (NIST) has done in the past, providing Federal agencies with assistance in establishing electronic mail connectivity. This project is sponsored by the General Services

Administration (GSA).

Appendix C: How to Obtain QUIPU, PP and ISODE 

                          ISODE/QUIPU 7.0

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

o The ISODE is not proprietary, but it is not in the public 

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

o The ISODE runs on native Berkeley (4.2, 4.3) and AT&T System V 

  systems, in addition to various other UNIX-like operating
  systems.  No kernel modifications are required.

o Current modules include: 

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

  -  OSI session, presentation, and association control services

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

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

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

     3.  Element-parser (basic encoding rules)

  -  OSI reliable transfer and remote operations services

  -  OSI directory services

  -  OSI file transfer, access and management

  -  FTAM/FTP gateway

  -  OSI virtual terminal (basic class, TELNET profile)

o ISODE 7.0 consists of final "IS" level implementations with the 

  exception of VT which is a DIS implementation.  The ISODE also

  contains implementations of the 1984 X.400 versions of ROS and
  RTS.

o Although the ISODE is not "supported" per se, it does have a 

  problem reporting address, [email protected].  Bug reports
  (and fixes) are welcome by the way.

o The discussion group [email protected] is used as an open 

  forum on ISODE.  Contact [email protected] to be added
  to this list.

o The primary documentation for this release consists of a five 

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

                  ISODE/QUIPU Distribution Sites

The FTP or FTAM distributions of ISODE-7.0 consists of 3 files. The source and main ISODE-7.0 distribution is in the file ISODE-7.tar.Z which is approximately 4.7MB in size.

LaTeX source for the entire document set can be found in the ISODE- 7-doc.tar.Z file (3.5MB). A list of documents can be found in the doc/ directory of the source tree.

A Postscript version of the five volume manual can be found in the ISODE-7-ps.tar.Z file (4.3MB).

If you can FTP to the Internet, then use anonymous FTP to uu.psi.com [136.161.128.3] to retrieve the files in BINARY mode from the ISODE/ directory. 

             Additional PSI White Pages Pilot Software

The 'usconfig' program configures a DSA which understands some of the NADF naming rules. This software is primarily intended for creating directory hierarchies for DSAs from scratch. The add-on software is available via anonymous FTP from uu.psi.com in: 

  wp/src/wpp-addon.tar.Z

Whether you choose to use 'usconfig' or not, please retrieve and install the addon, and follow the instructions therein. You might

want to retrieve pilot-ps.tar.Z again also, as it contains an updated Administrator Guide.

Note that the wpp-addon.tar.Z file needs to be installed on top of the ISODE 7.0 distribution; it does not duplicate any of the ISODE 7.0, you need to retrieve and generate that too. 

                              PP 6.0

PP is a Message Transfer Agent, intended for high volume message switching, protocol conversion, and format conversion. It is targeted for use in an operational environment, but is also be useful for investigating message related applications. Good management features are a major aspect of this system. PP supports the 1984 and 1988 versions of the CCITT X.400 / ISO 10021 services and protocols. Many existing RFC-822 based protocols are supported, along with RFC- 1148bis conversion to X.400. PP is an appropriate replacement for MMDF or Sendmail. This is the second public release of PP, and includes substantial changes based on feedback from using PP on many sites.

o PP is not proprietary and can be used for any purpose. The only 

  restriction is that suing of the authors for any damage the
  code may cause is not allowed.

o PP runs on a range of UNIX and UNIX-like operating systems, 

  including SUNOS, Ultrix, and BSD.  A full list of platforms on
  which PP is know to run is included in the distribution.

o Current modules include: 

  -  X.400 (1984) P1 protocol.

  -  X.400 (1988) P1 protocol.

  -  Simple mail transfer protocol (SMTP), conformant to host
     requirements.

  -  JNT mail (grey book) Protocol.

  -  UUCP mail transfer.

  -  DECNET Mail-11 transfer

  -  Distribution list expansion and maintenance, using either a
     file based mechanism or an X.500 directory.

  -  RFC 822-based local delivery.

  -  Delivery time processing of messages.

  -  Conversion between X.400 and RFC-822 according to the latest
     revision of RFC-1148, known as RFC-1148bis.

  -  Conversion support for reformatting body parts and headers.

  -  X-Window and line-based management console.

  -  Message Authorization checking.

  -  Reformatting support for "mail hub" operation.

  -  X.500-based distribution list facility using the QUIPU
     directory.

  -  FAX interworking

o No User Agents (UAs) are included with PP. However, procedural 

  access to the MTA is documented, to encourage others to write
  or to port UAs.  Several existing UAs, such as MH, may be used
  with PP.

o It is expected that a Message Store to be used in conjunction 

  with PP (PPMS), and an associated X-Windows User Agent (XUA)
  will be released on beta test in first quarter 92.

o The core routing of PP 6.0 is table based. DNS is used by the 

  SMTP channel.  The next version of PP will support Directory
  Based routing, which may use X.500 or DNS.

o PP 6.0 requires ISODE 7.0.

o X-Windows release X11R4 (or greater) is needed by some of the 

  management tools.  PP can be operated without these tools.

o Although PP is not "supported" per se (but see later), it does 

  have a problem reporting address (bug reports (and fixes) are
  welcome):

  RFC-822:  [email protected]
  X.400:    S=PP-Support; OU=CS; O=UCL;
            PRMD=UK.AC; ADMD= ; C=GB;

o The discussion group [email protected] is used as an open 

  forum on PP; Contact [email protected] to be added
  to this list.

o The primary documentation for this release consists of a three 

  and a half volume User's Manual (approx. 300 pages) and a set
  of UNIX manual pages.  The sources to the User's Manual are in
  LaTeX format.

                       PP Distribution Sites

If you can FTP to the Internet from outside Europe, then use anonymous FTP to uu.psi.com [136.161.128.3] to retrieve the file pp- 6.tar.Z in binary mode from the ISODE/ directory. This file is the tar image after being run through the compress program and is approximately 3Mb in size.

If you can FTP to the Internet from Europe, then use anonymous FTP to archive.eu.net [192.16.202.1] to retrieve the file pp-6.tar.Z in binary mode from the network/ISODE/ directory. This file is the tar image after being run through the compress program and is approximately 3Mb in size. 

         ISODE/QUIPU and PP Platforms as of December 1991

Machine OS ISODE PP Stacks Notes

========================================================

CCUR 6000 RTU 5.0 7.0 Yes! TCP 1

CCUR 6000 RTU 6.0 7.0 Yes! TCP 2 

                                                     X25
                                                     CLNS

CDC 4000 Series EP/IX 1.3.2 6.6+ TCP 3 

                EP/IX 1.4.1                          CLNS
                                                     X25

COMPAQ 386/25 SCO Unix 5.2 6.0 TCP

COMPAQ 386 BSD 7.0 TCP 4 

                                                     X25

Convex C120 ConvexOS 8.1 7.0 TCP 5

DEC Vax 2nd Berkeley Network rel 7.0 TCP 

                                                     X25

DEC DECnet-ULTRIX V5.0 7.0 TCP 6 

                                                     CLNS

DEC Ultrix 3.1D 7.0 5.2 TCP 7 

                Ultrix 4.0                           X25

                Ultrix 4.1

DEC Ultrix 4.2 7.0 TCP 

                                                    X25
                                                    CLNS

DEC VMS v5.x 7.0 TCP 

                                                    X25

DG Avion DGUX 4.30 7.0 TCP 8

Encore Multimax 3xx UMAX V 2.2h 6.0 TCP 9 Encore Multimax 5xx

Encore NP1 UTX/32 3.1a 7.0 TCP 10 

                                                    X25

Encore PN6000 UTX/32 2.1b 6.0 TCP 9 Encore PN9000 X25

HP/9000/3xx HP/UX 6.0 7.0 TCP 11 

                HP-UX 7.05 B

HP/9000/8xx HP-UX 7.00 7.0 TCP 11 

                                                    X25

IBM 3090 AIX/370 1.2.1 7.0 TCP 12

IBM PS/2 AIX 1.2.1 6.7 TCP 13

IBM RS/6000 AIX 3.1 6.8 TCP 

                AIX 3.0

ICL DRS/6000 7.0 5.2 TCP 14

Macintosh A/UX 2.0.1 7.0 TCP

Macintosh MacOS V6.x 6.0 TCP 15

Mips 4-52 ATT-V3-0 7.0 5.2 TCP 16

NeXT 7.0 5.2 TCP 17

ORION/Clipper 6.8 TCP

Olivetti LSX-3020 X/OS 2.1 6.7b 5.0 TCP 1 

                                                    X25

Pyramid 9800 OSx 5.1 (4.3BSD/SVR3.2) 7.0 5.2 TCP 18 Pyramid MIS

SEQUENT DYNIX V3.0.18 7.0 TCP 8

Sony News-1750 NEWS-OS 3.3 6.8 TCP 

                NEWS-OS 4.0c

Sun4 SunOS 4.1 7.0 5.2 TCP Sun3 SunOS 4.1.1 X25 

                SunOS 4.0.3c                        CONS
                                                    CLNS

Notes:

1. NOT SNMP or VT

2. Little tested

3. Official upper layer

4. Prototype only!

5. Planned port

6. Being worked on!

7. 3.1D binaries compiled under 4.2

8. Only QUIPU confirmed

9. Not QUIPU

10. Need "-Dregister=" in CONFIG.make

11. Need bug-fix no. 5 from [email protected]. not SNMP,VT or 

    FTAM-FTP gateway

12. No VT, QUIPU not tested

13. Models 80 and 95

14. NOT SNMP or VT,PP and X.25 requires patches available from 

    X-Tel

15. Using MacTCP

16. Only QUIPU tested, built using BSD43 config

17. Need bug-fix no. 6 from [email protected]

18. Built using BSD config, no VT or SNMP

The above tables do not refer to beta releases of ISODE and PP more recent than the public ISODE-7.0 or PP-5.2 releases. The above table is generated from reports sent to bug-ISODE and pp-support. There is no guarantee the information is correct.

Appendix D: Sample X.500 Input File and Restricted Character List

Below is a sample datafile that illustrates the format for providing data about persons at your site to be loaded into the ESnet DSA. Following the sample datafile is a detailed explanation of the format and content of the file. We have tried to be as flexible as possible in defining the format of the file, given the constraints imposed by an automated process. We would appreciate feedback on the format of the file and will try to accommodate any specific needs you may have to any extent that is reasonable.

  2. Sample Data File for Bulk Loading X.500 Database
  4. delimiter character is "," 1
  5. field 1 is commonName 2
  6. field 2 is phone extension 3
  7. area code for all numbers is 510 4
  8. prefix for all numbers is 422 5
  9. field 3 is rfc822Mailbox 6
  10. field 4 is facsimileTelephoneNumber 7
  11. default facsimileTelephoneNumber is (510) 422-3333 8
  12. postalAddress for all entries is: 9
  13. National Energy Research Supercomputer Center 10
  14. P.O. Box 5509 11
  15. Livermore, California 94552 12

Chris Anderson,1915,[email protected], 13 Lila Brown,5680,[email protected], 14 Bob Green,4474,, 15 Max Jones,4488,[email protected],5104224444 16 Dave Smith,9818,[email protected], 17 Cathy White,4016,[email protected], 18 <end-of-file>

Comment lines at the beginning of the file convey relevant formatting information.

Following comment lines, each data line contains information about one person.

Fields within a single data line are separated by a delimiter character. You specify the delimiter character you wish to use in the comment section; be sure to choose a delimiter which does not appear as a legitimate character in any field of a data line.

You may provide all or part of the attribute types listed in the table in Section 2.5 (commonName is required). In the comment section, you must indicate which attribute types are contained in each field of a data line.

Each data line must contain the same number of fields and the same order of fields (i.e. same order of attribute types). Two successive delimiters indicated a null value (eof is a considered a field delimiter).

The characters "=", "&", "$", and "#" are NEVER allowed in any attribute value.

Below is a discussion of relevant lines of the sample datafile.

Line 1 The delimiter character is identified as a comma (,).

Line 2 Field # 1 is identified as containing the commonName 

             attribute.

Line 3 Field # 2 is identified as containing the telephoneNumber 

             attribute.  The actual data value is a 4-digit
             extension.

Lines 4,5 Identify the area code and prefix which apply to all 

             4-digit extensions in the datafile.  If your actual
             data values already contain area code and/or prefix,
             then there would be no need to indicate default values.

Line 6 Field # 3 is identified as containing the rfc822Mailbox 

             attribute.

Line 7 Field # 4 is identified as containing the 

             facsimileTelephoneNumber attribute.

Line 8 Identifies the default value for 

             facsimileTelephoneNumber.  If field 4 is missing in a
             data line, the default value will be applied.

Lines 9-12 Identify the value of the postalAddress attribute which 

             applies to all entries.

Line 13 commonName= Chris Anderson 

        surName= Anderson
        telephoneNumber= 510-422-1915
        rfc822MailBox= [email protected]
        facsimileTelephoneNumber= 510-422-3333
        postalAddress= National Energy Research Supercomputer Center
                       P.O. Box 5509
                       Livermore, California 94552

Line 14 commonName= Lila Brown 

        surName= Brown
        telephoneNumber= 510-422-5680
        rfc822MailBox= [email protected]
        facsimileTelephoneNumber= 510-422-3333
        postalAddress= National Energy Research Supercomputer Center
                       P.O. Box 5509
                       Livermore, California 94552

Line 15 commonName= Bob Green 

        surName= Green
        telephoneNumber= 510-422-4474
        rfc822MailBox=
        facsimileTelephoneNumber= 510-422-3333
        postalAddress= National Energy Research Supercomputer Center
                       P.O. Box 5509
                       Livermore, California 94552

Line 16 commonName= Max Jones 

        surName= Jones
        telephoneNumber= 510-422-4488
        rfc822MailBox= [email protected]
        facsimileTelephoneNumber= 510-422-4444
        postalAddress= National Energy Research Supercomputer Center
                       P.O. Box 5509
                       Livermore, California 94552

Line 17 commonName= Dave Smith 

        surName= Smith
        telephoneNumber= 510-422-9818
        rfc822MailBox= [email protected]
        facsimileTelephoneNumber= 510-422-3333
        postalAddress= National Energy Research Supercomputer Center
                       P.O. Box 5509
                       Livermore, California 94552

Line 18 commonName= Cathy White 

        surName= White
        telephoneNumber= 510-422-4016
        rfc822MailBox= [email protected]
        facsimileTelephoneNumber= 510-422-3333
        postalAddress= National Energy Research Supercomputer Center
                       P.O. Box 5509
                       Livermore, California 94552

Appendix E: ESnet Backbone Sites 

                        Government Agencies

U.S. Department of Energy, Office of Energy Research (DOE) Germantown, Maryland USA

U.S. Department of Energy, San Francisco Office (SAN) Oakland, California USA 

                       National Laboratories

NASA Ames Research Center (AMES, FIX-WEST) Mountain View, California USA

Argonne National Laboratory (ANL) Argonne, Illinois USA

Brookhaven National Laboratory (BNL) Upton, New York USA

Continuous Electron Beam Accelerator Facility (CEBAF) Newport News, Virginia USA

Fermi National Accelerator Laboratory (FNAL) Batavia, Illinois USA

Lawrence Berkeley Laboratory (LBL) Berkeley, California USA

Lawrence Livermore National Laboratory (LLNL) Livermore, California USA

Los Alamos National Laboratory (LANL) Los Alamos, New Mexico USA

Oak Ridge National Laboratory (ORNL) Oak Ridge, Tennessee USA

Pacific Northwest Laboratory (PNL) Richland, Washington USA

Princeton Plasma Physics Laboratory (PPPL) Princeton, New Jersey USA

Sandia National Laboratory, Albuquerque (SNLA) Albuquerque, New Mexico USA

Stanford Linear Accelerator Center (SLAC) Menlo Park, California USA

Superconducting Super Collider (SSC) Dallas, Texas USA 

                           Universities

California Institute of Technology (CIT) Pasadena, California USA

Florida State University (FSU) Tallahassee, Florida USA

Iowa State University (ISU) Ames, Iowa USA

Massachusetts Institute of Technology (MIT) Cambridge, Massachusetts USA

New York University (NYU) Upton, New York USA

Oak Ridge Associated Universities (ORAU) Oak Ridge, Tennessee USA

University of California, Los Angeles (UCLA) Westwood, California USA

University of Maryland (UMD, FIX-EAST) College Park, Maryland USA

University of Texas, Austin (UTA) Austin, Texas USA 

                        Commercial Entities

General Atomics (GA) San Diego, California USA

Office of Science and Technology Information (OSTI) Oak Ridge, Tennessee USA

Science Applications, Incorporated (SAIC) McLean, Virginia USA

Appendix F: Local Site Contacts for DOE Naming Authorities

Below is a list of all Department of Energy GOSIP Site Authorities for OSI registration and addressing. This information was obtained from the DoE GOSIP On-Line Information System (DOE-GOIS), dated November 18, 1991.

Marian F. Sotel Director, Information management Division U.S. Department of Energy DOE Field Office, Albuquerque

Dennis Jensen Ames Laboratory 258H Development Ames, IA 50011-3020 (515) 294-7909

Linda Winkler Argonne National Laboratory Argonne, IL 60439 (708) 972-7236

R. E. Kremer Manager, Resource Automation U.S. Department of Energy Bettis Atomic Power laboratory

Gary Ragsdale Manager, Information Services U.S. Department of Energy Bonneville Power Administration 905 NE 11th Avenue Portland, OR 97232

Wayne Larson Head of Data Communications Unit U.S. Department of Energy Bonneville Power Administration 905 NE 11th Avenue Portland, OR 97232

George Rabinowitz Head Distributed Computing Section Brookhaven National Laboratory Upton, New York 11973 (516) 282-7637

Donna A. Dyxin Communications Specialist U.S. Department of Energy DOE Field Office, Chicago 9800 South Cass Avenue Argonne, IL 60439

Elaine R. Liebrecht System Manager and Planning Supervisor EG&G Mound Applied Technologies P.O. Box 3000 Miamisburg, OH 45343-3000 (FTS) 774-3733 or (513) 865-3733

Jeffrey J. Johnson Communications Supervisor EG&G Mound Applied Technologies P.O. Box 3000 Miamisburg, OH 45343-3000 (FTS) 774-4230 or (513) 865-4230

Paul P. Herr U.S. Department of Energy Energy Information Agency (202) 586-7318

William H. Foster U.S. Department of Energy Energy Information Agency (202) 586-6310

Mark O. Kaletka Data Communications Group Leader, Computing Div. Fermi National Accelerator Lab P.O. Box 500 Batavia, IL 60510 (708) 840-2965

David A. Mackler Grand Junction Project Office (FTS) 326-6412

Wayne L. Selfors Grand Junction Project Office (FTS) 326-6525

Gerald F. Chappell Director, ITSO U.S. Department of Energy Headquarters Washington D.C., 20545 (FTS) 233-3685 or (301) 903-3685

Joe Diel Supervisor, Biomathematics Group ITRI

David H. Robinson Section Supervisor, Information Systems Allied-Signal Aerospace Company Kansas City Division P.O. Box 419159 Kansas City, MO 64141-6159 (FTS) 997-3690 or (816) 997-3690

Robert M. Jensen Supervisory Engineer, Information Systems Allied-Signal Aerospace Company Kansas City Division P.O. Box 419159 Kansas City, MO 64141-6159 (FTS) 997-5538 or (816) 997-5538

Russell Wright Lawrence Berkeley Laboratories 1 Cyclotron Road Berkeley, CA 94720 (510) 486-6965

William A. Lokke Associate Director for Computation Lawrence Livermore National Lab (FTS) 532-9870 or (669) 422-9870

Philip Wood/Glenn Michel Los Alamos National Laboratory Los Alamos, NM 87545 (FTS) 843-1845 or (FTS) 843-2598

Robert Bruen MIT Laboratory for Nuclear Science Computer Facilities Manager Massachusetts Institute of Tech. Cambridge, MA

Mark Cerullo Morgantown Energy Technology Center (FTS) 923-4345

Hank Latham NVRSN (FTS) 575-7646

Bill Morrison Network Specialist Bechtel Petroleum Operations, Inc Naval Petroleum Reserves California P.O. Box 127 Tupman, CA 93276 (FTS) 797-6933 or (805) 763-6933

Mary Ann Jones DOE Field Office, Nevada

Bill Freberg Computer Sciences Corporation DOE Field Office, Nevada

Roger Hardwick Project Director Roy F. Weston OCRWM 3885 S. Decatur Blvd. Las Vegas, NV 89103 (702) 873-6200

John Gandi U.S. Department of Energy OCRWM 101 Convention Ctr Phase II Complex, Suite 202 Las Vegas, NV 89109 (702) 794-7954

Benny Goodman U.S. Department of Energy OSTI

Raymond F. Cook U.S. Department of Energy OSTI

D. M. Turnpin Martin Marietta Energy Systems, Inc Oak Ridge P.O. Box 2009 Oak Ridge, TN 37831-8227 (FTS) 626-8848 or (615) 576-8848

T. E. Birchfield Supervisor, Electronic Informations Delivery Sect. Martin Marietta Energy Systems, Inc Oak Ridge P.O. Box 2008 Oak Ridge, TN 37831-6283 (FTS) 624-4635 or (615) 574-4635

Bobby Brumley TRESP Associates DOE Field Office, Oak Ridge

Mike Letterman TRESP Associates DOE Field Office, Oak Ridge

S. Dean Carpenter Department Head, Communications Mason and Hanger Pantex Plant

Wayne C. Phillips Section Head, Internal Communications Mason and Hanger Pantex Plant

A. J. Lelekacs Sr. Networking Engineer General Electric Pinellas Plant P.O. Box 2908 Neutron Devices Department Largo, FL 34649-2908

Paul A. Funk Site Access Coordinator Princeton Plasma Physics Laboratory P.O. Box 451 Princeton, NJ 08543 (609) 243-3403

John Murphy Branch Chief, Information and Communication Mgmt U.S. Department of Energy DOE Field Office, Richland P.O. Box 550 Richland, WA 99352 (FTS) 444-7543 or (509) 376-7543

Mike Schmidt Telecom & Network Services IRM Westinghouse Hanford Company DOE Field Office, Richland P.O. Box 1970 Richland, WA 99352 (FTS) 444-7739 or (509) 376-7739

Dwayne Ramsey Information Resources Management Division U.S. Department of Energy DOE Field Office, San Francisco (FTS) 536-4302

W. F. Mason Central Computing Systems Manager Sandia National Laboratories - AL P.O. Box 5800 Albuquerque, NM 87185 (FTS) 845-8059 or (505) 845-8059

Harry R. Holden U.S. Department of Energy DOE Field Office, Savannah River P.O. Box A Aiken, SC 29802 (FTS) 239-1118 or (803) 725-1118

Reggie Peagler Network Security Officer Savannah River Site Building 773-51A Aiken, SC 29808 (FTS) 239-3418 or (803) 557-3418

Wade A. Gaines Acting ADP Manager U.S. Department of Energy Southeastern Power Administration Samuel Elbert Building Elberton, GA 30635

Paul Richard Southwestern Power Administration (FTS) 745-7482

Dr. R. Les Cottrell Assistant Director, SLAC Computer Services Stanford Linear Accelerator Center P.O. Box 4349 Stanford, CA 94309

John Lucero Systems Analyst, Management Systems Westinghouse Electric Corporation Waste Isolation Pilot Plant P.O. Box 2078 Carlsbad, NM 88221 (FTS) 571-8459 or (505) 887-8459

Lawrence Bluhm Sr. Systems Analyst, Management Systems Westinghouse Electric Corporation Waste Isolation Pilot Plant P.O. Box 2078 Carlsbad, NM 88221 (FTS) 571-8459 or (505) 887-8459

Ben Sandoval Western Area Power Administration (FTS) 327-7470

John Sewell Western Area Power Administration (FTS) 327-7407

Appendix G: Recommended Reading 

                    RFCs (Request For Comments)

The following RFCs may be obtained from the ESnet Information Server. They are stored in the directory [ANONYMOUS.RFCS]. They may be retrieved via anonymous FTP (nic.es.net, 128.55.32.3) or DECnet copy (ESNIC::, 41.174).

RFC1328 X.400 1988 to 1984 downgrading. Hardcastle-Kille, S.E. 1992 

 May; 5 p. (Format: TXT=10006 bytes)

RFC1327 Mapping Between X.400 (1988) /ISO 10021 and RFC 822. 

 Hardcastle-Kille, S.E.  1992 May; 113 p. (Format: TXT=228598 bytes)

RFC1309 Technical overview of directory services using the X.500 

 protocol.  Weider, C.; Reynolds, J.K.; Heker, S.  1992 March; 4 p.
 (Format: TXT=35694 bytes)

RFC1308 Executive Introduction to Directory Services Using the X.500 

 Protocol.  Weider, C.; Reynolds, J.K.  1992 March; 4 p. (Format:
 TXT=9392 bytes)

RFC1295 North American Directory Forum. User bill of rights for 

 entries and listing in the public directory.  1992 January; 2 p.
 (Format: TXT=3502 bytes)

RFC1292 Lang, R.; Wright, R. Catalog of Available X.500 

 Implementations. 1991 December; 103 p. (Format: TXT=129468 bytes)

RFC1279 Hardcastle-Kille, S.E. X.500 and domains. 1991 November; 13 

 p. (Format: TXT=26669, PS=170029 bytes)

RFC1278 Hardcastle-Kille, S.E. String encoding of presentation 

 address. 1991 November; 5 p. (Format: TXT=10256, PS=128696 bytes)

RFC1277 Hardcastle-Kille, S.E. Encoding network addresses to support 

 operations over non-OSI lower layers.  1991 November; 10 p.
 (Format: TXT=22254, PS=176169 bytes)

RFC1276 Hardcastle-Kille, S.E. Replication and distributed operations 

 extensions to provide an Internet directory using X.500. 1991
 November; 17 p. (Format: TXT=33731, PS=217170 bytes)

RFC1275 Hardcastle-Kille, S.E. Replication requirements to provide an 

 Internet directory using X.500.  1991 November; 2 p. (Format:
 TXT=4616, PS=83736 bytes)

RFC1274 Kille, S.E.; Barker, P. COSINE and Internet X.500 schema. 1991 

 November; 60 p. (Format: TXT=92827 bytes)

RFC1255 North American Directory Forum. Naming scheme for c=US. 1991 

 September; 25 p. (Format: TXT=53783 bytes)  (Obsoletes RFC 1218)

RFC1249 Howes, T.; Smith, M.; Beecher, B. DIXIE protocol 

 specification.  1991 August; 10 p. (Format: TXT=20693 bytes)

RFC1202 Rose, M.T. Directory Assistance service. 1991 February; 11 p. 

 (Format: TXT=21645 bytes)

RFC1006 Rose, M.T.; Cass, D.E. ISO transport services on top of the 

 TCP: Version 3.  1987 May; 17 p. (Format: TXT=31935 bytes)

                     Non Published Working Notes

"A String Representation of Distinguished Names", S.E. Hardcastle-Kille, 

 01/30/1992.

 The OSI Directory uses distinguished names as the primary keys to
 entries in the directory.  Distinguished Names are encoded in
 ASN.1. When a distinguished name is communicated between to users
 not using a directory protocol (e.g., in a mail message), there is
 a need to have a user-oriented string representation of
 distinguished name.

"An Access Control Approach for Searching and Listing", S.E. 

 Hardcastle-Kille, T. Howes, 09/23/1991.

 This memo defines an extended ACL (Access Control List) mechanism
 for the OSI Directory.  It is intended to meet strong operational
 requirements to restrict searching and listing externally, while
 allowing much more freedom within an organization.  In particular,
 this mechanism makes it possible to restrict searches to certain
 sets of attributes, and to prevent "trawling": the disclosure of
 large organizational data or structure information by repeated
 searches or lists. This capability is necessary for organizations
 that want to hide their internal structure, or to prevent dumping
 of their entire database.  This memo describes functionality
 beyond, but compatible with, that expected in the 1992 X.500
 standard.

"Building an Internet Directory using X.500", S. Kille, 01/07/1991. 

 The IETF has established a Working Group on OSI Directory Services.
 A major component of the initial work of this group is to establish
 a technical framework for establishing a Directory Service on the

 Internet, making use of the X.500 protocols and services.  This
 document summarizes the strategy established by the Working Group,
 and describes a number of RFCs which will be written in order to
 establish the technical framework.

"Directory Requirements for COSINE and Internet Pilots (OSI-DS 18)", 

 S.E. Hardcastle-Kille, 07/09/1991.

 This document specifies operational requirements for DUAs and DSAs
 in the Internet and COSINE communities.  This document summarizes
 conformance requirements.  In most cases, technical detail is
 handled by reference to other documents.  This document refers to
 core directory infrastructure. Each application using the directory
 may impose additional requirements.

"DSA Naming", S.E. Hardcastle-Kille, 01/24/1992. 

 This document describes a few problems with DSA Naming as currently
 deployed in pilot exercises, and suggests a new approach.  This
 approach is suggested for use in the Internet Directory Pilot,
 which overcomes a number of existing problems, and is an important
 component for the next stage in increase of scale.

"Handling QOS (Quality of service) in the Directory", S.E. Kille, 

 08/29/1991.

 This document describes a mechanism for specifying the Quality of
 Service for DSA Operations and Data in the Internet Pilot Directory
 Service "Building and internet directory using X.500".

"Interim Directory Tree Structure for Network Infrastructure 

 Information", Chris Weider, Mark Knopper, Ruth Lang, 06/14/1991.

 As work progresses on incorporating WHOIS and Network
 Infrastructure information into X.500, we thought it would be
 useful to document the current DIT structure for this information,
 along with some thoughts on future expansion and organization of
 this subtree of the DIT. The first section of this document
 describes the current structure, the second section the possible
 expansion of the structure.

"Interim Schema for Network Infrastructure Information in X.500 New 

 name:  Encoding Network Addresses to support operation ov", Chris
 Weider, Mark Knopper, 06/14/1991.

 As the OSI Directory progresses into an operational structure which
 is being increasingly used as a primary resource for Directory
 Information, it was perceived that having the Internet Site

 Contacts and some limited network information in the Directory
 would be immediately useful and would also provide the preliminary
 framework for some distributed NIC functions. This paper describes
 the interim schema used to contain this information.

"Naming Guidelines for Directory Pilots", P. Barker, S.E. Kille, 

 01/30/1992.

 Deployment of a Directory will benefit from following certain
 guidelines. This document defines a number of naming guidelines.
 Alignment to these guidelines will be recommended for national
 pilots.

"OSI NSAP Address Format For Use In The Internet", R Colella, R Callon, 

 02/13/1991.

 The Internet is moving towards a multi-protocol environment that
 includes OSI. To support OSI, it is necessary to address network
 layer entities and network service users.  The basic principles of
 OSI Network Layer addressing and Network Service Access Points
 (NSAPs) are defined in Addendum 2 to the OSI Network service
 definition.  This document recommends a structure for the Domain
 Specific Part of NSAP addresses for use in the Internet that is
 consistent with these principles.

"Representing Public Archives in the Directory", Wengyik Yeong, 

 12/04/1991.

 The proliferation of publicly accessible archives in the Internet
 has created an ever-widening gap between the fact of the existence
 of such archives, and knowledge about the existence and contents of
 these archives in the user community. Related to this problem is
 the problem of also providing users with the necessary information
 on the mechanisms available to retrieve such archives.  In order
 for the Internet user community to better avail themselves of this
 class of resources, there is a need for these gaps in knowledge to
 be bridged.

"Schema for Information Resource Description in X.500", Chris Weider, 

 06/14/1991.

 The authors are interested in allowing distributed access and
 updating for Information Resource Description information to users
 of the Internet. This paper discusses the schema used to hold the
 Information Resource Description information.  The new attributes
 are taken from the US-MARC fields, and subfields, with the mapping
 described in the text.

"Schema for NIC Profile Information in X.500", Chris Weider, Mark 

 Knopper, 06/14/1991.

 The authors of this document, in conjunction with the chairs of the
 IETF Network Information Services Infrastructure (NISI) group,
 would like to implement a Directory of Network Information Centers,
 or NICs.  This will enable NICs to find each other easily, will
 allow users with access to a DSA to find out where NICs are, and
 will in general facilitate the distribution of information about
 the Internet and some of its infrastructure.  This document
 proposes a set of standard schema for this information.

"Using the OSI Directory to Achieve User Friendly Naming", S. Kille, 

 01/30/1992.

 The OSI Directory has user friendly naming as a goal.  A simple
 minded usage of the directory does not achieve this.  Two aspects
 not achieved are:  1)  A user oriented notation  and  2)
 Guessability. This proposal sets out some conventions for
 representing names in a friendly manner, and shows how this can be
 used to achieve really friendly naming.  This then leads to a
 specification of a standard format for representing names, and to
 procedures to resolve them. This leads to a specification which
 allows directory names to be communicated between humans.  The
 format in this specification is identical to that defined in the
 reference of "A String Representation of Distinguished Name", and
 it is intended that these specifications are compatible.

"Requirements for X.400 Management Domains (MDs) Operating in the Global 

 Research and Development X.400 Service", R. Hagens, 11/12/1991.

 This  document  specifies  a  set  of  minimal   operational
 requirements that  must  be  implemented  by all Management Domains
 (MDs) in the Global R&D X.400 Service.   This  document  defines
 the  core  operational requirements; in some cases, technical
 detail is handled  by  reference  to other documents.  The Global
 R&D X.400 Service is defined as all organizations which meet the
 requirements described in this document.

"Routing Coordination for X.400 MHS Services within a 

 Multiprotocol/Multinetwork Environment", U. Eppenberger,
 10/25/1992.

 The X.400 addresses do start to appear on business cards. The
 different MHS service providers are not well interconnected and
 coordinated which makes it a very hard job for the MHS managers to
 know where to route all the new addresses. A big number of X.400
 implementations support different lower layer stacks. Taking into

 account the variety of existing large transport networks, there is
 now the chance of implementing a worldwide message handling service
 using the same electronic mail standard and therefore without the
 need of gateways with service reduction and without the restriction
 to a single common transport network. This document proposes how
 messages can travel over different networks by using multi stack
 MTAs as relays. Document formats and coordination procedures bridge
 the gap until an X.500 directory service is ready to store the
 needed connectivity and routing information.

                  International Standards Documents

International Consultative Committee for Telephone and Telegraph. Open 

 Systems Interconnection - The Directory. X.500 Series
 Recommendations.  December, 1988.

 (also published as)

ISO/IEC. Information Technology - Open Systems Interconnection - The 

 Directory. International Standard 9594. 1989.

International Consultative Committee for Telephone and Telegraph. Data 

 Communication Networks - Message Handling Systems. X.400 Series
 Recommendations. Geneva 1985.

International Consultative Committee for Telephone and Telegraph. Data 

 Communication Networks - Message Handling Systems. X.400 Series
 Recommendations. Melbourne, 1988.

                           NIST Documents
     (National Institute of Standards and Technology Documents)

The following documents can be retrieved from the ESnet Information Server in directory [ANONYMOUS.NIST].

Government Open Systems Interconnection Profile (GOSIP) Version 1, 

 National Institute of Standards and Technology, Federal Information
 Processing Standards Publication #146, August, 1988.

Government Open Systems Interconnection Profile (GOSIP) Version 2, 

 National Institute of Standards and Technology, October, 1990.

                            DOE Documents

The following documents prepared by the DOE GOSIP Migration Working Group can be retrieved from the ESnet Information Server in directory [ANONYMOUS.DOE-GOSIP].

U.S. Department of Energy. Government Open Systems Interconnection 

 Profile.  Transition Strategy. DOE GOSIP Document # GW-ST-008.
 November, 1990.

U.S. Department of Energy. Government Open Systems Interconnection 

 Profile.  Transition Plan. DOE GOSIP Document # GW_PN_005.
 November, 1990.

U.S. Department of Energy. Government Open Systems Interconnection 

 Profile.  Procedures and Guidelines. DOE GOSIP Document # GW-PR-
 007. April, 1991.

                         IETF Working Groups

Three IETF working groups, OSI X.400, OSI-DS and MHS-DS have been working in in X.400 and X.500. Minutes of meetings, descriptions of the working groups' charters and goals, information about mailing lists, and other pertinent documents can be retrieved from the ESnet Information Server in the directories [ANONYMOUS.IETF.OSIDS], [ANONYMOUS.IETF.OSIX400] and [ANONYMOUS.IETF.MHSMS]. 

                              Others

Marshall T. Rose, Julian P. Onions and Colin J. Robbins. The ISO 

 Development Environment: User's Manual, 1991.  ISODE Documentation
 Set.

Marshall T. Rose and Wengyik Yeong. PSI White Pages Pilot Project: 

 Administrator's Guide, 1991.  ISODE Documentation Set.

Marshall T. Rose. The Open Book: A Practical Perspective on Open 

 Systems Interconnection. Prentice-hall, 1990. ISBN 0-13-643016-3.

Marshall T. Rose. The Little Black Book: Mail Bonding with OSI 

 Directory Services. Prentice-hall, 1991. ISBN 0-13-683219-5.

Alan Turner and Paul Gjefle, Pacfic Northwest Laboratory. Performance 

 Analysis of an OSI X.500 (QUIPU) Directory Service Implmentation.
 1992. Available on nic.es.net in the directory [ANONYMOUS.ESNET-
 DOC]QUIPU-PERF.PS

Appendix H: Task Force Member Information

Bob Aiken 

 U.S. Department of Energy, Office of Energy Research, Scientific
 Computing Staff (now with National Science Foundation)
 Email:  [email protected]

Joe Carlson 

 Lawrence Livermore National Laboratory
 Livermore, California USA
 Email:  [email protected]

Les Cottrell 

 Stanford Linear Accelerator Center
 Menlo Park, California USA
 Email:  [email protected]

Tim Doody 

 Fermi National Accelerator Laboratory
 Batavia, Illinois USA
 Email:  [email protected]

Tony Genovese (Contributing Author) 

 Lawrence Livermore National Laboratory
 Livermore, California USA
 Email:  [email protected]

Arlene Getchell (Contributing Author) 

 Lawrence Livermore National Laboratory
 Livermore, California USA
 Email:  [email protected]

Charles Granieri 

 Stanford Linear Accelerator Center
 Menlo Park, California USA
 Email:  [email protected]

Kipp Kippenhan (Contributing Author) 

 Fermi National Accelerator Laboratory
 Batavia, Illinois USA
 Email:  [email protected]

Connie Logg 

 Stanford Linear Accelerator Center
 Menlo Park, California USA
 Email:  [email protected]

Glenn Michel 

 Los Alamos National Laboratory
 Los Alamos, New Mexico USA
 Email:  [email protected]

Peter Mierswa 

 Digital Equipment Corporation USA

Jean-Noel Moyne 

 Lawrence Berkeley Laboratory
 Berkeley, California USA
 Email:  [email protected]

Kevin Oberman (Contributing Author) 

 Lawrence Livermore National Laboratory
 Livermore, California USA
 Email:  [email protected]

Dave Oran 

 Digital Equipment Corporation USA

Bob Segrest 

 Digital Equipment Corporation USA

Tim Streater 

 Stanford Linear Accelerator Center
 Menlo Park, California USA
 Email:  [email protected]

Allen Sturtevant (Chair, Contributing Author, Document Editor) 

 Lawrence Livermore National Laboratory
 Livermore, California USA
 Email:  [email protected]

Mike Sullenberger 

 Stanford Linear Accelerator Center
 Menlo Park, California USA
 Email:  [email protected]

Alan Turner (Contributing Author) 

 Pacific Northwest Laboratory
 Richland, Washington USA
 Email:  [email protected]

Linda Winkler (Contributing Author) 

 Argonne National Laboratory
 Argonne, Illinois USA
 Email:  [email protected]

Russ Wright (Contributing Author) 

 Lawrence Berkeley Laboratory
 Berkeley, California USA
 Email:  [email protected]

Security Considerations

Security issues are discussed in sections 2.5.1 and 2.7.5.1 of this memo.

Authors' Addresses

Allen Sturtevant Lawrence Livermore National Laboratory P.O. Box 5509; L-561 Livermore, CA 94551

Phone: +1 510-422-8266 Email: [email protected]

Tony Genovese Lawrence Livermore National Laboratory P.O. Box 5509; L-561 Livermore, CA 94551

Phone: +1 510-423-2471 Email: [email protected]

Arlene Getchell Lawrence Livermore National Laboratory P.O. Box 5509; L-561 Livermore, CA 94551

Phone: +1 510-423-6349 Email: [email protected]

H. A. Kippenhan Jr. Fermi National Accelerator Laboratory Wilson Hall 6W, MS-234 P.O. Box 500 Batavia, IL 60150

Phone: +1 708-840-8068 Email: [email protected]

Kevin Oberman Lawrence Livermore National Laboratory P.O. Box 5509; L-156 Livermore, CA 94551

Phone: +1 510-422-6955 Email: [email protected]

Alan Turner Pacific Northwest Laboratory P.O. Box 999; K7-57 Richland, WA 99352

Phone: +1 509-375-6670 Email: [email protected]

Linda Winkler Argonne National Laboratory 9700 South Cass Avenue Building 221 B251 Argonne, IL 60439

Phone: +1 708-252-7236 Email: [email protected]

Russ Wright Lawrence Berkeley Laboratory 1 Cyclotron Road MS 50B-2258 Berkeley, CA 94720

Phone: +1 510-486-6965 Email: [email protected]

Retrieved from "https://rfc-wiki.org/index.php?title=RFC1330&oldid=19449"