diff options
Diffstat (limited to 'doc/rfc/rfc1330.txt')
| -rw-r--r-- | doc/rfc/rfc1330.txt | 4875 |
1 files changed, 4875 insertions, 0 deletions
diff --git a/doc/rfc/rfc1330.txt b/doc/rfc/rfc1330.txt new file mode 100644 index 0000000..a761a7e --- /dev/null +++ b/doc/rfc/rfc1330.txt @@ -0,0 +1,4875 @@ + + + + + + +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. + +Table of Contents + + Status of this Document ....................................... 4 + Acknowledgments ............................................... 4 + + + +ESCC X.500/X.400 Task Force [Page 1] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + 1 Introduction ............................................... 5 + 1.1 Abstract and Introduction ................................ 5 + 1.2 Structure of this Document ............................... 5 + 2 X.500 - OSI Directory Services ............................. 6 + 2.1 Brief Tutorial ........................................... 6 + 2.2 Participation in the PSI White Pages Pilot Project ....... 7 + 2.3 Recommended X.500 Implementation ......................... 7 + 2.4 Naming Structure ......................................... 8 + 2.4.1 Implications of the Adoption of RFC-1255 by PSI ........ 9 + 2.4.2 Universities and Commercial Entities ................... 10 + 2.4.3 Naming Structure Below the o=<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.5 Services Provided by ESnet ............................... 29 + + + +ESCC X.500/X.400 Task Force [Page 2] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + 3.5.1 X.400 Operations Mailing List .......................... 30 + 3.5.2 MTA Routing Table on ESnet Information Server .......... 30 + 3.5.3 MTA Routing Table Format ............................... 30 + 3.5.4 Gateway Services and Multiprotocol Stack Support ....... 30 + 3.5.5 Registering/Listing your PRMD or Organizational MTA 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 G: Recommended Reading .............................. 77 + Appendix H: Task Force Member Information .................... 83 + Security Considerations ....................................... 86 + Authors' Addresses ............................................ 86 + + + + + + + + + + + + + + +ESCC X.500/X.400 Task Force [Page 3] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + Recommendations for the Phase I Deployment 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 + + + +ESCC X.500/X.400 Task Force [Page 4] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + +1. Introduction + +1.1. 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. + +1.2. 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 + + + +ESCC X.500/X.400 Task Force [Page 5] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + private/commercial X.400 routing are discussed. + + Finally, the issues in name registration with ANSI (American National + Standards Institute), GSA (General Services Administration) and the + U.S. Department of Commerce, Patent and Trademark Office (PTO) are + discussed. + +2. X.500 - OSI Directory Services + +2.1. 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 + + + +ESCC X.500/X.400 Task Force [Page 6] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + directory, and how users access the information. There are 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. + +2.2. 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. + +2.3. 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 + + + +ESCC X.500/X.400 Task Force [Page 7] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + extensions. + + To ensure interoperability for the entire ESnet community, 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. + +2.4. 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 + + + +ESCC X.500/X.400 Task Force [Page 8] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + provided in Appendix E. + + Directly connected ESnet backbone sites will be responsible 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. + +2.4.1. 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 + + + +ESCC X.500/X.400 Task Force [Page 9] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + register with ANSI to have their organization list directly 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. + +2.4.2. 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". + +2.4.3. 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 + + + +ESCC X.500/X.400 Task Force [Page 10] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + manager will probably want to enlist input from others within 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 + + + +ESCC X.500/X.400 Task Force [Page 11] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + System Administrator have entries. Upon getting the 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." + + + + +ESCC X.500/X.400 Task Force [Page 12] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + Ruth Lang of SRI: + + "There has been no SRI-wide policy or decision to 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." + +2.5. Information Stored in X.500 + + The Phase I deployment of X.500 should be limited to "white pages"- + + + +ESCC X.500/X.400 Task Force [Page 13] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + type information about people. Other types of objects can be 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 Sturtevant@es.net + 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. + +2.5.1. Information Security + + It is understood that placing this type of information in X.500 is + equivalent to putting the "Company Phone Book" on-line in the + Internet. Different sites may treat this information differently. + Some may view it as confidential, while others may view this data as + open to the public. In any case, it was recommended that ESnet sites + discuss the implications with their respective legal departments + before actually making their information openly available. There + currently exists minimal access control in several X.500 + implementations. + +2.6. 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 + + + +ESCC X.500/X.400 Task Force [Page 14] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + Mail) make use of capabilities or services which already reside on + many workstations and hosts. Such hosts could immediately take + advantage of the X.500 service with no additional software or + reconfiguration needed. However, since these methods are non- + interactive, they only provide a way to search for and read + information in the Directory but no way to modify information. + +2.6.1. Directory Service via WHOIS + + The Pilot Project software allows you to configure the X.500 + Directory service to be made available via a network port offering an + emulation of the SRI-NIC WHOIS service. UNIX-based hosts and VMS + hosts running Multinet typically come configured with the WHOIS + service. Users at their workstations would then be able to issue a + simple WHOIS command to a known host running a DSA to retrieve + information about colleagues at their site or at other ESnet sites. + For example, the command: + + whois -h wp.lbl.gov wright + + will return information about Russ Wright at Lawrence Berkeley Lab. + It is recommended that all sites which bring up such a service, + should provide an alias name for the host running their DSA of the + form <wp.site.domain> for consistency within the ESnet community. + +2.6.2. Directory Service via Electronic Mail + + The Pilot Project software also allows the X.500 Directory service to + be made available via electronic mail. A user who sends an + electronic mail message to a known host running a DSA containing a + WHOIS-like command on the subject line, would then receive a return + mail message containing the results of their query. + +2.6.3. Directory Service via FINGER + + The X.500 Directory service could also be made available via the + FINGER service. Although this access method does not come with the + PSI Pilot Project software, several sites have already implemented a + FINGER interface to the X.500 Directory. For ease of use and + consistency, a single FINGER interface should be selected, then + individual implementations within the ESnet community should conform + to this interface. + +2.6.4. Directory Service via Specialized Applications + + Many X.500 Directory User Agents (DUAs) are widely available. Some + of these come with the PSI Pilot Project software. Other DUAs, which + have been developed by third parties to fit into the pilot software, + + + +ESCC X.500/X.400 Task Force [Page 15] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + are publicly available. These user agents support interactive access + to the X.500 Directory allowing browsing, searching, listing and + modifying data in the Directory. However, in most cases, use of + these DUAs requires the Pilot Project software be installed on the + host system. Only a few of these DUAs and their capabilities are + described below. + + o DISH - A User Agent which provides a textual interface to the + X.500 Directory. It gives full access to all elements of the + Directory Access Protocol (DAP) and as such may be complex for + novice users. DISH is most useful to the DSA administrator. + + o FRED - A User Agent which has been optimized for "white pages" + types of queries. The FRED program is meant to be similar to + the WHOIS network service. FRED supports reading, searching, + and modifying information in the X.500 Directory. + + o POD - An X-windows based User Agent intended for novice users. + POD relies heavily on the concept of the user "navigating" + around the DIT. Pod supports reading and searching. There are + no facilities to add entries or to modify the RDNs of entries, + though most other entry modifications are allowed. + +2.6.5. Directory Service from PCs and MACs + + Smaller workstations and personal computers lack the computing power + or necessary software to implement a full OSI protocol stack. As a + consequence, several "light-weight" protocols have been developed + whereby the DAP runs on a capable workstation and exports a simpler + interface to other end-systems. One such "light weight" protocol, + the Directory Assistance Service (DAS), is incorporated in the PSI + Pilot Project software. Another "light weight" protocol, DIXIE, was + developed at the University of Michigan. Publicly available User + Agents for both the MAC and PC have been developed using the DA- + service and the DIXIE protocol. So long as you have the Pilot + Project software running on one host, you can provide these User + Agents on many end-systems without having to install the Pilot + software on all those end-systems. + + For further information about available Directory User Agents, see + RFC-1292, "Catalog of Available X.500 Implementations". + +2.7. Services Provided by ESnet + + Currently, there are several ESnet backbone sites which are operating + their own DSAs within the PSI White Pages Pilot Project. It is + anticipated that directly connected ESnet backbone sites will + eventually install and operate their own X.500 DSAs. In the interim, + + + +ESCC X.500/X.400 Task Force [Page 16] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + ESnet will provide complete support for ESnet backbone sites which + presently do not have the time, expertise or equipment to establish + X.500 services. The mechanism for doing this is described in Section + 2.7.5 below. Additionally, ESnet will provide a variety of services + in support of the entire X.500 community. These are also described + in the following sections. + +2.7.1. X.500 Operations Mailing List + + ESnet maintains a mailing list for the discussion of relevant X.500 + topics. This mailing list provides a means for sharing information, + experiences, and expertise about X.500 in the ESnet community. New + sites joining the ESnet X.500 community will be announced on the + mailing list. New DSA administrators will be able to solicit help + from more experienced administrators. When a site brings up a new + X.500 DSA, the DSA manager should notify the ESnet DSA manager so as + to ensure they are promptly added to the mailing list. + + General discussion: x500-ops@es.net + To subscribe: x500-ops-request@es.net + +2.7.2. Accessing the X.500 Directory + + ESnet has made the X.500 service openly available to the entire ESnet + community via each of the access methods described in Section 2.6 + above. Host WP.ES.NET provides TELNET access, FINGER and WHOIS + emulations, querying via electronic mail, as well as remote access + via light-weight protocols. By making these services widely + available, we hope to acquaint more users with the features and + capabilities of X.500. + + To try out some of the X.500 User Agents, simply TELNET to WP.ES.NET + and login as user "fred"; no password is required. You have the + choice of running the Fred or Pod User Agents. Fred provides a + command line interface while Pod provides an X-windows based + interface. You can browse through the global X.500 DIT, search for + persons in various organizations, and even modify your own entry if + you have one. + + Host WP.ES.NET also provides access to the X.500 Directory via + emulations of the FINGER and WHOIS utilities. These interfaces + support a user-friendly-naming (UFN) scheme that simplifies the + syntax necessary to search for persons in other organizations. 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): + + + + + +ESCC X.500/X.400 Task Force [Page 17] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + whois -h wp.es.net leighton,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". + +2.7.3. Backbone Site Aliases + + As ESnet backbone sites join the X.500 pilot, their organizations' + entries will be placed in various parts of the DIT. For example, + National Laboratories will be placed directly under the c=US portion + of the DIT, while universities and commercial entities will most + likely be placed under localities, such as states or cities. + + In order to facilitate searching for the ESnet community as a whole, + ESnet backbone sites will also be listed as organizational units + under the node "@c=US@o=Energy Sciences Network". These entries will + actually be aliases which point to the site's "real" organizational + entry. Therefore, ESnet backbone sites will be listed in two + different places in the DIT and one could search for them in either + location. + +2.7.4. Multiprotocol Stack Support + + OSI applications currently run over many different transport/network + protocols, a factor which hinders communication between OSI end + nodes. In order to facilitate communication, the ISODE may be + configured at compile time to support any combination of the + following stacks: + + RFC-1006 over TCP/IP + TP0 over X.25 + TP0 over X.25 (84) + TP0 over the TP0-bridge + TP4 over CLNP + + Within the ESnet community, the stacks of interest are RFC-1006 over + TCP/IP, TP4 over CLNP, and TP0 over X.25. If a backbone site's DSA + is not running over all three of these stacks, it may eventually + receive referrals to a DSA that it can not connect to directly, so + the operation can not proceed. Since the ESnet DSAs will be + configured to operate over all of the "stacks of interest," they can + serve as relay DSAs between site DSAs that do not have direct + connectivity. The site's DSA manager will need to contact the ESnet + DSA manager to arrange for this relaying to occur. Backbone sites + + + +ESCC X.500/X.400 Task Force [Page 18] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + will be encouraged to eventually provide as many of the three stacks + of interest as possible. + +2.7.5. Managing a Site's X.500 Information + + For sites which do not initially wish to operate their own DSA, + ESnet's DSA will master their site's portion of the DIT, enabling the + site to join the PSI Pilot Project and the ESnet X.500 community. In + order to accomplish this, the site must provide the ESnet DSA manager + with information about the people to be included in the X.500 + Directory. This information can usually be obtained from your Site's + Personnel Database. + + ESnet will only maintain a limited amount of information on behalf of + each person to be represented in the Directory. The attribute types + listed in the table in Section 2.5 show the maximum amount of + information which the ESnet DSA will support for a person's entry in + the Directory. This set of attribute types is a small subset of the + attribute types offered by the PSI Pilot Project software. + Therefore, if a site wishes to include additional attribute types, + they should consider installing and operating their own DSA. + + The format of the information to be provided to the ESnet DSA manager + is as follows: the data should be contained in a flat, ASCII text + file, one record (line) per person, with a specified delimiter + separating the fields of the record. More detailed information and a + sample of a site-supplied data file can be found in Appendix D. + +2.7.5.1. Open Availability of Site Information + + Although the PSI Pilot Project allows you to control who may access + Directory objects and their attributes, any information you provide + about persons at your site to be stored in the ESnet DSA will be + considered world readable. This policy is necessary in order to + minimize the administrative cost of managing potentially many + organizational objects within the ESnet DSA. If your site decides + that it does not wish to have certain information about its employees + publicly known (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. + +2.7.5.2. Access Methods for Local Users + + Backbone sites which choose the option of having the ESnet DSA master + their organization's X.500 information should make the availability + of the X.500 service known to their local users. All of the methods + described in Section 2.7.2 are available for use, but none of these + methods will assume the query is relative to the local site. + + + +ESCC X.500/X.400 Task Force [Page 19] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + To facilitate querying relative to the local environment, the site + will need to make one host available to run the emulation of the + FINGER service. Although the resulting query will ultimately be + directed to the remote ESnet DSA, the search will appear to be local + to the users at that site. For example, a user on a workstation at + site XYZ could type the following, omitting their local domain name + as this is implied: + + finger jones@wp + + This will retrieve information about user Jones at site XYZ (wp is + the name or alias of a host at site XYZ, i.e. wp.XYZ.GOV). The site + coordinator will need to contact the ESnet DSA manager to arrange the + set up for this service. + +2.7.5.3. Limitations of Using ESnet Services + + Since the ESnet DSA will potentially be mastering information on + behalf of numerous backbone sites, limits will need to be placed on + the volume of site information stored in the ESnet DSAs. These are + enforced to ensure DSA responsiveness, as well as to reduce + administrative maintenance. The limits are: + + 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 x500-ops@es.net mailer to remind the sites that an update cycle + is approaching. If no changes are required to the site information, + the reminder message can be ignored and the existing version of this + information will be used. If the information is to be updated, a + complete replacement of all information must be supplied to the ESnet + DSA manager before the next update cycle. More detailed information + and a sample of a site-supplied data file can be found in Appendix D. + +2.8. ESnet Running a Level-0 DSA for c=US + + For ESnet to provide high quality X.500 services to the ESnet + community, the ESnet DSAs must operate as Level-0 (first level) DSAs. + It is currently planned that these DSAs will act as slave, Level-0 + DSAs to PSI's master, Level-0 DSAs. Once the ESnet DSAs are in + + + +ESCC X.500/X.400 Task Force [Page 20] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + production service, it is recommended that directly connected ESnet + backbone sites operating their own X.500 DSAs configure them with one + of the ESnet DSAs as their parent DSA. This provides several + advantages to the ESnet community: + + 1. The ESnet DSAs will be monitored by the NERSC's 24-hour + Operations Staff. Additionally, ESnet plans to deploy two + (2) DSAs in geographically disperse locations to ensure + reliability and availability. + + 2. All queries to Level-0 DSAs remain within the ESnet high-speed + backbone. + + 3. If network connectivity is lost to all external Level-0 DSAs, + X.500 Level-0 connectivity will still exist within the ESnet + backbone. + +2.9. X.500 Registration Requirements + + X.500 organization names must be nationally unique if they appear + directly below the c=US level in the DIT structure. Nationally + unique names must be registered through an appropriate registration + authority, 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 + + + +ESCC X.500/X.400 Task Force [Page 21] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + use of X.500 in two ways: + + 1. Lookup of message recipient information. + + 2. Lookup of message routing information. + + X.400 technology and products, as they stand today, do not support + both of these features in a fully integrated fashion across multiple + vendors. As the standards and technology evolve, consideration will + have to be given in applying these new functions to the production + ESnet X.500/X.400 services environment. + +2.10.3. Use of X.500 for NIC Information + + Work is currently being performed in the IETF to place NIC + information on-line in an Internet-based X.500 service. + +2.10.4. Use of X.500 for Non-White Pages Information + + The PSI White Pages Pilot Project has caused increasing and popular + use of X.500 as a white pages services within the Internet community. + However, the X.500 standard provides for much more than just this + service. Application processes, devices and security objects are + just a few of the objects to be considered for future incorporation + in the global X.500 database. + +2.10.5. Introduction of New X.500 Implementations + + Thought will have to be given to the use of commercial X.500 products + in the future as QUIPU (the implementation recommended in this paper) + may not meet all of the needs of the ESnet community. As commercial + products mature and become stable, they will have to be incorporated + into the ESnet X.500 service in a way which ensures interoperability + and reliability. + +2.10.6. Interaction of X.500 and DECdns + + There is every indication that DECdns and X.500 will interoperate in + some fashion in the future. Since there is an evolving DECdns + namespace (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. + + + + + + + +ESCC X.500/X.400 Task Force [Page 22] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + +3. X.400 - OSI Message Handling Services + +3.1. Brief Tutorial + + In 1984 CCITT defined a set of protocols for the exchange of + electronic messages called Message Handling Systems (MHS) and is + described in their X.400 series of recommendations. ISO incorporated + these recommendations in their standards (ISO 10021). The name used + by ISO for their system was MOTIS (Message-Oriented Text Interchange + Systems). In 1988 CCITT worked to align their X.400 recommendations + with ISO 10021. Currently when people discuss messaging systems they + use the term X.400. These two systems are designed for the general + purpose of exchanging electronic messages in a store and forward + environment. The principle use being made of this system today is to + support electronic mail. This section will give an overview of X.400 + as used for electronic mail. In the following sections, the term + X.400 will be used to describe both the X.400 and MOTIS systems. + + The basic model used by X.400 MHS is that of a Message Transfer + System (MTS) accessed via a User Agent (UA). A UA is an application + that interacts with the Message Transfer System to submit messages on + behalf of a user. A user is referred to as either an Originator + (when sending a message) or a Recipient (when receiving one). The + process starts out when an Originator prepares a message with the + assistance of their UA. The UA then submits the message to the MTS + for delivery. The MTS then delivers the message to one or more + Recipient UAs. + + _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ + ______ | _______ _______ | ______ + | | | MTS | | | | | | | + | UA |<----|---->| MTA |<------>| MTA |<---|--->| UA | + |______| | |_______| |_______| | |______| + |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _| + + The MTS provides the general store-and-forward message transfer + service. It is made up of a number of distributed Message Transfer + Agents (MTA). Operating together, the MTAs relay the messages and + deliver them to the intended recipient UAs, which then makes the + messages available to the recipient (user). + + The basic structure of an X.400 message is an envelope and content + (i.e. message). The envelope carries information to be used when + transferring the message through the MTS. The content is the piece + of information that the originating UA wishes delivered to the + recipient UA. There are a number of content types that can be + carried in X.400 envelopes. The standard user message content type + defined by X.400 is called the Interpersonal (IP) message. An IP + + + +ESCC X.500/X.400 Task Force [Page 23] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + message consists of two parts, the heading and body. The heading + contains the message control information. The body contains the user + message. The body may consist of a number of different body parts. + For example one IP message could carry voice, text, Telex and + facsimile body parts. + + The Management domain (MD) concept within the X.400 recommendations + defines the ownership, operational and control boundary of an X.400 + administration. The collection consisting of at least one MTA and + zero or more UAs owned by an organization or public provider + constitutes a management domain (MD). If the MD is managed by a + public provider it is called an Administration Management Domain + (ADMD). The MD managed by a company or organization is called a + Private Management Domain (PRMD). A Private MD is considered to + exist entirely within one country. Within that country a PRMD may + have access to one or more ADMDs. + + Each MD must ensure that every user (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 + + + +ESCC X.500/X.400 Task Force [Page 24] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + portion of their O/R Name until arrival at the recipient MD. At + which point, the other attributes in the name are used to further + route to the recipient UA. Internal routing within a MD is the + responsibility of each MD. + +3.2. ESnet X.400 Logical Backbone + + Currently within the ESnet community message handling services are + implemented with a number of different mail products, resulting in + what is classically known as an "n-squared" problem. For example, + let's say that LLNL only uses QuickMail on site, PPPL only uses + MAIL-11 (VMS MAIL), and CEBAF only uses SMTP mail. For LLNL to send + mail to PPPL and CEBAF, is must support MAIL-11 and SMTP locally on- + site. Likewise for PPPL to send mail to LLNL and CEBAF, it must + support MAIL-11 and QuickMail locally. Identically, this scenario + exists for CEBAF. + + To alleviate this problem, a logical X.400 backbone must be + established through out the entire ESnet backbone. Then, each ESnet + backbone site will be responsible for only providing connectivity + between it's local mail domains (QuickMail, MAIL-11, SMTP Mail, or + even native X.400) and the logical X.400 backbone. One of the long- + term goals is to establish X.400 as the "common denominator" between + directly connected ESnet backbone sites. + +3.3. Naming Structure + + The name-spaces for X.500 and X.400 are completely different and are + structured to meet different needs. The X.500 name-space is + typically organized to allow quick, optimized searching; while the + X.400 ORname is used to forward an X.400 message through several + "levels" of MTAs (X.400 Message Transfer Agents). + + ESnet backbone sites will participate in the X.400 environment + through one of two options; either participating in the ESnet Private + Management Domain (PRMD) or operating a site PRMD. For most sites, + utilizing the ESnet PRMD will be the simpler and preferable choice. + +3.3.1. Participating in the ESnet Private Management Domain + + ESnet backbone sites participating in the ESnet PRMD will have an + X.400 name syntax as follows: + + /.../O=<site>/PRMD=ESnet/ADMD= /C=US/ + + A few examples of a possible X.400 ORnames using the above syntax + are: + + + + +ESCC X.500/X.400 Task Force [Page 25] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + /PN=Smith/OU=Computations/O=LLNL/PRMD=ESnet/ADMD= /C=US/ + /PN=Jones/OU=Physics/O=PPPL/PRMD=ESnet/ADMD= /C=US/ + + These sites will operate an MTA at the /O=<organization> level in the + name hierarchy. + +3.3.2. Operating a Site Private Management Domain + + ESnet backbone sites which operate a PRMD will have an X.400 name + syntax as follows: + + /.../O=<org>/PRMD=<site>/ADMD= /C=US/ + + A few examples of a possible X.400 ORnames using the above syntax + are: + + /PN=Smith/O=Computations/PRMD=LLNL/ADMD= /C=US/ + /PN=Jones/O=Physics/PRMD=PPPL/ADMD= /C=US/ + + These sites will operate an MTA at the /PRMD=<PRMD> level in the name + hierarchy. This MTA will peer with the ESnet PRMD MTA. + +3.3.3. Detailed Name Structure + + GOSIP places several limits on allowable ORnames. After the + /O=<organization> name, up to four levels of + /OU=<organizational_unit> names are allowed. The ORname string is + then completed with the /PN=<personal_name> field. + + All ORname fields must use characters from the ISO printable + character set. Additionally, the following name length restrictions + apply: + + PRMD Names 16 characters + Organization Names 64 characters + Organizational Unit Names 32 characters + Personal Names 64 characters + + NOTE: A 40 character limit for Personal Names is now being + studied by the CCITT. + + Within these name constraints, the architecting of an organization's + name space is a local matter. Sites are encouraged to consider ease + of use and stability when determining their naming structure. + +3.4. X.400 Routing + + In the IP environment a SMTP MTA could use the Domain Name Service + + + +ESCC X.500/X.400 Task Force [Page 26] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + (DNS) to locate connection information for the host closest to the + recipient. With X.400, MTAs must know the remote MTAs name and + password along with connection information. This is because of + access control requirements on some X.400 systems. In X.400 MHS this + information will, at some future date, be provided by X.500. In the + mean time the routing and connection process within the X.400 + community is table driven. This solution requires a coordination and + distribution effort to ensure a quick and reliable update of these + tables. + + The current thinking on the problem of X.400 routing is to decompose + the X.400 address space into a hierarchy, with each node in this + hierarchy representing the entry point for an X.400 domain. These + nodes have been commonly called Well Known Entry Points (WEPs). Each + of these WEPs represent one X.400 MHS domain. 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/ + + + + +ESCC X.500/X.400 Task Force [Page 27] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + to a well-known entry point for PPPL (O=PPPL). PPPL must own and + operate their own X.400 MTA, and it must be configured to accept + X.400 messages from the ESnet MTA. Thus, the interpretation of + remaining "/PN=Funk/OU=CS" is left to the PPPL MTA to route. + + Mail sent from PPPL's MTA would be routed to the ESnet's MTA (PRMD) + to be eventually routed to its destination. + + The ESnet MTA will also route to peer MTAs which are well-known entry + points for other PRMDs (e.g. ESnet backbone site PRMDs, XNREN, Hughes + Air Craft, NASA, CDC). For example, the ESnet MTA would route a + message with the address: + + /PN=Smith/OU=MS/O=RL/PRMD=PNL/ADMD= /C=US/ + + to a well-known entry point for PNL (PRMD=PNL). PNL must own and + operate their own X.400 MTA, and it must be configured to accept + X.400 messages from the ESnet MTA (as well as possibly other PRMDs). + Thus, the interpretation of the remaining "/PN=SMITH/OU=MS/O=RL" is + left to the PNL MTA to route. + + Mail sent from PNL's MTA (PRMD) would be routed to the well-known + entry point for the PRMD indicated in the destination address. + + Additionally, a site operated PRMD must be able to route mail to any + other peer-PRMD within the ESnet community. + +3.4.1. Responsibilities in Operating an X.400 PRMD MTA + + If the X.400 world were to operate exactly as the standard + recommends, PRMDs would only peer with other PRMDs when connectivity + is available and traffic demand is sufficient, and would utilize ADMD + services to reach all other PRMDs. In reality, many PRMDs will not + subscribe to an ADMD service and will only be reachable through PRMD + peering. + + Most communities, such as the ESnet, desire the fullest PRMD + interconnectivity possible to minimize the need for ADMD services. + Community PRMD operational requirements stem from a policy of + achieving large scale peering among PRMD operators within the + community. + + Work is continuing in the IETF X.400 Operations Working Group to + produce an RFC that specifies the operational requirements that must + be implemented by X.400 Management Domains. "Requirements for X.400 + Management Domains (MDs) Operating in the Global Research and + Development X.400 Service", this document is listed in Appendix G. + ESnet will comply with all the requirements outlined in this + + + +ESCC X.500/X.400 Task Force [Page 28] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + document. It is the recommendation that all ESnet PRMDs follow the + requirements specified in this document. + + As an overview, this document specifies that each PRMD will provide + at least one WEP and that all PRMDs must be interconnected. There + are a number of PRMDs in the International X.400 service that have + different communication stack requirements. For example: + + Stack 1 Stack 2 Stack 3 Stack 4 + ------- ------- ------- ------- + Transport Layer 4 TP0 TP4 RFC-1006 TP0 + Network Service 1-3 X.25 CLNS TCP/IP CONS + + To meet the requirement that all PRMDs must be interconnected a PRMD + must support one or more of the above stacks. For stacks that are + not supported the PRMD must negotiate with another PRMD or ADMD to + relay messages to a Management Domain that does support the other + stacks. + + The PRMD requirements also suggest that PRMDs support downgrading of + X.400 1988 to X.400 1984. Also, the PRMD must be reachable from the + Internet Mail service. This means the PRMD must maintain an Internet + Mail/X.400 gateway. + + In all cases, members of the ESnet community who operate a PRMD + should notify ESnet of the WEP and MTA information required to + perform peering. + +3.4.2. Responsibilities in Operating an X.400 Organizational MTA + + ESnet will provide PRMD service to the ESnet community. ESnet will + peer with the other PRMDs in the International X.400 service and + provide a WEP for the ESnet community. An Organization/site needs to + decide if they are going to comply with the above PRMD requirements + or act as an organization associated to the ESnet PRMD. Minimally, + an organizational MTA will only have to support one of the protocol + stacks provided by it associated PRMD. But in all cases, the site + will need to provide a WEP and register/list their MTA(s) with ESnet. + +3.5. Services Provided by ESnet + + ESnet will provide PRMD service to those members of the ESnet + community who desire it. ESnet will peer with other PRMDs in the + International community (e.g. XNREN, Hughes Air Craft, NASA, CDC) and + provide a WEP for the ESnet community; the intent is to provide the + fullest PRMD level X.400 services. + + ESnet will deploy two, PRMD level, X.400 MTAs in geographically + + + +ESCC X.500/X.400 Task Force [Page 29] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + disperse locations. These MTAs will be able to forward mail for + directly connected ESnet backbone sites, as well as to and from the + peered PRMDs. + +3.5.1. X.400 Operations Mailing List + + ESnet will provide an X.400 operations mailer for announcements and + to allow the sharing of X.400 operational information in the ESnet + community. + + General discussion: x400-ops@es.net + To subscribe: x400-ops-request@es.net + +3.5.2. MTA Routing Table on ESnet Information Server + + ESnet will maintain forwarding information about ESnet community MTAs + at the /PRMD=<PRMD> or /O=<organization> levels (depending on what + level the site MTA is operating). This information will be available + for use in configuring directly connected ESnet site operated MTAs. + This information will be made available in a machine independent + format on the ESnet Information Server. + +3.5.3. MTA Routing Table Format + + The ESnet staff will determine the details of information format, + update frequency, obtaining, and disseminating the information based + on operational experience and constraints. + +3.5.4. Gateway Services and Multiprotocol Stack Support + + The ESnet MTAs will minimally support bidirectional SMTP-X.400 mail + gateway capabilities, and will operate over the OSI CLNS protocol (as + defined by GOSIP) and RFC-1006 stacks. Configuration and operation + of mail protocol gateway functions will be governed by the ESnet + staff. + + Backbone site MTAs which service ORnames at the /O=<site> level under + the ESnet PRMD must utilize one of the ESnet PRMD supported protocol + stacks. This requirement assures that all users of the ESnet PRMD + will be able to communicate to one another via the ESnet PRMD MTA. + + Backbone site MTAs which service ORnames in PRMDs other than + /PRMD=ESnet must utilize the OSI CLNS stack for GOSIP conformance. + Use of the RFC-1006 stack is optional. This requirement assures that + all PRMDs in the ESnet community will be able to peer with the ESnet + PRMD. + + + + + +ESCC X.500/X.400 Task Force [Page 30] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + +3.5.5. Registering/Listing your PRMD or Organizational MTA with ESnet + + To provide for the connection and routing requirements in X.400 you + will need to register/list your MTA with ESnet. This information + will be maintained in tables on the ESnet Information Server. ESnet + will also maintain information on the International X.400 service. + ESnet will use the same format for information as maintained by the + International X.400 service. This is described in detail in a IETF + X.400 operations paper "Routing Coordination for X.400 MHS Services + within a Multiprotocol/Multinetwork Environment". This paper is a + working draft, see Appendix G. It describes a machine independent + form for distribution of X.400 information. + + There are three tables that must be maintained and exchanged by the + top level WEPS. + + 1. The Community Document + + 2. The WEP Document + + 3. The Domain Document + + ESnet will submit these documents to the International X.400 + community on behalf of the ESnet Community. If an ESnet PRMD wishes + to peer with the International PRMDs they will need to submit these + documents to that community. + + The Community document is used to list the central coordination point + and file server where all MHS documents will be stored. It also + lists the communication stacks used by the MHS community. This + document will be submitted to the International X.400 service by + ESnet for the ESnet Community. ESnet PRMDs and Organizations do not + need to submit this form to ESnet. If an ESnet PRMD wishes to peer + with the International X.400 service then they must submit this form + to that community. + + Each ESnet MHS domain will need to submit a WEP and Domain Document + to ESnet. The WEP document is used to list the WEPs used by an ESnet + MHS domain. It will contain all the information that is needed for + MTA connection and access control. ESnet will submit the ESnet + community WEP and Domain Documents to the International X.400 + service. The WEP document consists of a list of WEPs, with the + following information for each one: + + o The MTA Name + + o Password + + + + +ESCC X.500/X.400 Task Force [Page 31] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + o Which MTS supported + + o Which standard, 84 and/or 88 + + o Connection information outbound + + o Connection information inbound + + o Computer system information + + o Point of contact + + The Domain Document specifies all the X.400 domains managed by a + site. It indicates the person responsible and which WEP services + which Domain. This document contains the following information + repeated for each Domain: + + o X.400 Domain + + o Point of Contact + + o Relaying WEP(s) + +3.6. X.400 Message Routing Between ADMDS and PRMDS + + While ESnet will provide X.400 routing service for systems, it cannot + provide routing via commercial X.400 carriers at this time. The + FTS-2000 charge for routing X.400 messages is $.45 (US) plus X.25 + packet charges. This could result in a charge of several dollars for + large messages, a real possibility with the multi-media capacity of + X.400. The payment of this fee is not within the charter of ESnet + and the provision of a charging mechanism to charge member sites is + not currently contemplated. + +3.7. X.400 Registration Requirements + + It is recommended by the CCITT that all X.400 PRMD names be + nationally unique. This is a current CCITT agreement and allows + direct PRMD-PRMD peer routing. Since national uniqueness is + required, registration should be performed through an appropriate + registration authority (such as ANSI). + + X.400 organization names must be unique within a PRMD. There is no + need for national uniqueness. Registration of an X.400 organization + name should be conducted through the PRMD operator. + + The registration of X.400 names below the organization level are + usually a local matter. Uniqueness within the context of a superior + + + +ESCC X.500/X.400 Task Force [Page 32] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + name should always be maintained. + + See Section 4 for a more complete description of OSI registration + issues and procedures. + +3.8. Future X.400 Issues to be Considered + +3.8.1. X.400 Mail Routing to International DOE Researchers + + Currently there are DOE researchers located in Switzerland, Japan, + Germany, China and Brazil. PRMD level connectivity to these + international locations does not exist presently. Since ESnet is not + chartered to pay for commercial X.400 services on behalf of the ESnet + community, "buying" this service is not a viable option. + + There are efforts taking place to provide international X.400 service + over the (international) Internet. Once this becomes fully + operational, further research will have to be performed to see if + this provides the X.400 connectivity needed to support the DOE + researchers located abroad. + +3.8.2. X.400 (1984) and X.400 (1988) + + The ESnet MTAs will initially support the 1984 version of the X.400 + standard. As the use of 1988 X.400 becomes more prevalent, support + for the newer standard will need to be addressed. One important + point, once the ESnet MTAs become 1988 X.400 compliant, they will + also have so support "downgrading" to 1984 X.400 to ensure reliable + X.400 mail delivery to the ESnet community. + +3.8.3. X.400 Interaction with X.500 + + This is discussed in Section 2.10.2. + +4. OSI Name Registration and Issues + + Implementing OSI services requires that certain information objects + (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 + + + +ESCC X.500/X.400 Task Force [Page 33] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + forming the tree. + + Each object can be given a unique and unambiguous name by registering + the object's name with an OSI registration authority at an + appropriate level in the naming tree. + + OSI name registration authorities and their procedures are expected + to change over time. Since names are intended to be stable, these + changes (hopefully!) will have minimal impact on existing OSI name + registrations. + + This section describes the role of OSI registration authorities, the + difference between a "registration" and a "notification", and sources + of nationally unique names. Information about three OSI name + registration authorities; the American National Standards Institute + (ANSI), the General Services Administration (GSA), and the U.S. + Department of Energy (U.S. DOE); are given. + + Registration of a name often requires stating a "right" to that name. + However, an OSI name registration does not guarantee legal name + rights. Name rights should be reviewed by legal experts prior to + registration. Information about the U.S. Department of Commerce, + Patent and Trademark Office (PTO) (potentially useful in asserting or + defending name rights) is given below. + +4.1. Registration Authorities + + OSI names are obtained through OSI name registration authorities by a + registration process. The selection of which particular registration + authority to use is determined by the desired level of the OSI name + in the naming hierarchy, possible restrictions on the names allocated + by each registration authority, and the applicability rules (will + they service your request) of each registration authority. + + An OSI name registration authority allocates OSI names from the + particular naming-domain it controls. Every registration authority + can trace its naming authority to its parent registration authority, + and ultimately to the top (global) level of the naming hierarchy. + +4.2. Registration Versus Notification + + Registering an OSI name guarantees its uniqueness and lack of + ambiguity. For a name to be useful however, other parties (besides + the registration authority) will need to be notified of the name and + its usage. + + There is a clear distinction between registration (obtaining an OSI + name) and notification (informing others of a name and its use). + + + +ESCC X.500/X.400 Task Force [Page 34] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + Often the term "registration" is used to describe both activities, + this is a potential source of confusion. + + For example, NADF and PSI (see Section 2) are not OSI registration + authorities. NADF may operate state registration authorities in the + future, if delegated that administrative right by the states. PSI + operates an X.500 pilot project and needs to be notified of + registered names when organizations join their pilot. + + X.400 ADMD operators are also not OSI registration authorities, + although they accept notification of X.400 PRMD names used by their + customers. + + The PTO is not an OSI registration authority. PTO names have no + meaning in an OSI context. + +4.3. Sources of Nationally Unique Name Registration + + There are four potential sources of nationally unique names which are + of interest to the ESnet community. These are ANSI, GSA, U.S. DOE + and the states. An overview of the ANSI, GSA, and U.S. DOE + procedures are given in later sections. + + In order to maintain national uniqueness "constructed name syntax" is + used by GSA, U.S. DOE, and the states. The form of each name is + shown below, "name" is the name presented to the registration + authority for registration. + + 1. ANSI names are of the form "name". + + 2. GSA names are of the form "GOV+name". + + 3. U.S. DOE names are of the form "GOV+USDOE+name". + + 4. State names are of the form "CA+name" (using California). + + State name registration authorities are not in operation at this + time. The use of U.S. DOE as a nationally unique name registration + source is not recommended due to the awkwardness of a double + constructed name. + +4.4. How to Apply for ANSI Organization Names + + ANSI is the root U.S. source of OSI recognized nationally unique + organization names. ANSI registration costs $2500 and results in + both an alphanumeric name and an associated numeric name. These + names may be used for a variety of purposes in X.400, X.500, and + other OSI services. + + + +ESCC X.500/X.400 Task Force [Page 35] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + For ANSI OSI organization name registration forms and instructions, + you should send your request to: + + American National Standards Institute, Inc. + Attn: Beth Somerville + OSI Registration Coordinator + 11 West 42nd Street + New York, NY 10036 + Phone: (212) 642-4976 + + ANSI registration procedures include a 90 day public review period + during which name requests can be easily challenged. + + There is a mechanism to forward ANSI requests to the GSA, it is + discussed in the GSA section below. + +4.5. How to Apply for GSA Organization Names + + GSA is the registration authority for government use of GOSIP, their + registration services are free for federal government organizations. + Names assigned by GSA always begin with the characters "GOV+" and are + limited to 16 characters. By agreement with ANSI, these GSA assigned + names are national unique. + + For GSA OSI Organization Name registration forms and instructions, + you should send your request to: + + General Services Administration + Office of Telecommunications Services + Registration Services, Room 1221-L KBA + 18th and F Streets, N.W. + Washington, D.C. 20405 + +4.5.1. GSA Designated Agency Representatives + + When preparing the GSA registration form a designated agency + representative must sign where it says "Registration Official Name + and Signature". GSA will refuse requests missing this signature. + + The GSA designated Agency Representative for the Department of Energy + is: + + + + + + + + + + +ESCC X.500/X.400 Task Force [Page 36] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + Steve Hackman + Electronics Engineer + U.S. Department of Energy + AD-241.3/GTN + Washington, D.C. 20585 + Office Phone: (301) 903-6111 + Office FAX: (301) 903-4125 + E-Mail: hackman@gosip.xosi.doe.gov + +4.5.2. Forwarding of ANSI Registrations to GSA + + ANSI registration requests can be forwarded automatically to the GSA. + This is the equivalent of registering with both ANSI and GSA. The + result is two nationally unique OSI name registrations, "name" from + ANSI and "GOV+name" from GSA. + + There is no GOSIP requirement for GSA registration but many feel the + additional GSA registration may be useful. + + Assuming your organization is a federal government organization, + answer the last three questions on the ANSI registration form as + shown below: + + 1. Do you wish the information supplied in the request to remain + confidential? NO. + + 2. Do you wish to have your organization name registered with the + U.S. GOSIP Registration Authority (a.k.a. GSA)? YES. + + 3. Is your organization an organization of the Federal Government? + YES. + + You must indicate on the application form the approval of the GSA + designated agency representative (Steve Hackman). He does not sign + as "Signature of Requestor", but some notation of his approval must + be attached or GSA will reject the forwarded application. + +4.6. How to Apply for U.S. DOE Organization Names + + ESnet sites are encouraged to review the DOE GOSIP procedures and + guidelines in planning their GOSIP activities. This document does + not conflict with current DOE GOSIP policies. + + DOE can assign nationally unique names which are prefixed by the + string "GOV+USDOE+". Use of this name source is not recommended; + there is no apparent advantage in using U.S. DOE over GSA as a source + of nationally unique names. + + + + +ESCC X.500/X.400 Task Force [Page 37] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + Copies of current U.S. DOE GOSIP policies, guidelines, and + registration forms may be obtained through site DOE naming + authorities or Steve Hackman. + +4.7. Why Apply for a Trademark with the PTO? + + Legal issues may arise concerning the rights to use a desired name. + OSI name registrations are not intended to "legally protect" name + usage rights; that is not their function. + + Consultation with legal experts concerning the rights to use a name + being registered is strongly advised, this recommendation does not + offer specific legal guidance. Applying for a trademark may be + considered as a means to assert or protect the rights to a name. + + Per the PTO trademark application instructions there may be several + benefits in obtaining a trademark. + + o The filing date of the application is a constructive date of + first use of the mark in commerce (this gives registrant + nationwide priority as of the date). + + o The right to sue in Federal court for trademark infringement. + + o Constructive notice of claim of ownership. + + o Limited grounds for attacking a registration once it is five + years old. + +4.8. How to Apply for a Trademark with the PTO + + You should obtain a trademark application and detailed instructions + from the U.S. Department of Commerce, Patent and Trademark Office. + This can be done by mailing your request to the address below, or + calling the PTO at the phone number below: + + U.S. Department of Commerce + Patent and Trademark Office + Washington, D.C. 20231 + Phone: (703) 557-INFO + + NOTE: The following information is based on ESnet experience in + filing for a trademark based on prior use. + + After you receive your application, you will need to perform the + following steps. + + 1. Complete the written application form. If you have more than + + + +ESCC X.500/X.400 Task Force [Page 38] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + one name you are filing, you must complete a separate form for + each name. + + 2. Provide a black-and-white drawing of the mark. In the case + where there is no artwork, only text, the text must be + centered on the page in uppercase. + + 3. Provide a check in the amount of $175 (for each application) + made payable to the Commissioner of Patents and Trademarks. + + 4. Provide three specimens showing actual use of the mark on or + in connection with the goods or services. + + The class of goods/services associated with this trademark must be + specified on the registration form. The currently defined classes of + services are: + + 35 Advertising and business. + 36 Insurance and financial. + 37 Construction and repair. + 38 Communication. + 39 Transportation and storage. + 40 Material treatment. + 41 Education and entertainment. + 42 Miscellaneous. + + So, for example, there could be two (or more) "ESnet" trademarks, + with each trademark associated with a different service class. Thus, + trademarks are not nationally unique. + + Before submitting your form, you should see if your trademark is + already registered to someone else (for the service class you + specified). This is typically done by your legal department through + the PTO Trademark Search Library. + + Since the PTO form is a legal document, you must involve your legal + department and the documents may only be signed by someone who is a + legally recognized representative of your organization. For example, + in applying for the service mark "ESnet", the "Applicant Name" was + "The Regents of the University of California", and the legally + recognized representative was Dr. John Nuckolls, the director of the + Lawrence Livermore National Laboratory. + +4.9. Future Name Registration Issues to be Considered + +4.9.1. ANSI Registered ADMD and PRMD Names + + There are discussions in the ANSI and CCITT communities revolving + + + +ESCC X.500/X.400 Task Force [Page 39] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + around the idea of having a formal registration of all ADMD and PRMD + Names (not just ANSI Organization Names). The ideas being exchanged + include having a separate ANSI national registry for these names, and + having to pay a periodic "license" fee. This is just in the idea + discussion phase now, but it may impact the cost of ANSI ADMD and + PRMD Name registration in the near future. + +Glossary + +AA - See ADMINISTRATIVE AUTHORITY. + +ADDMD - See ADMINISTRATIVE DIRECTORY MANAGEMENT DOMAIN. + +ADMD - See ADMINISTRATION MANAGEMENT DOMAIN. + +ADMINISTRATION - An Administration denotes a public telecommunications + administration or other organization offering public + telecommunications services. + +ADMINISTRATION MANAGEMENT DOMAIN - An Administrative Management Domain + (ADMD) is a management domain managed by an Administration; + generally one of the common carriers (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). + + + +ESCC X.500/X.400 Task Force [Page 40] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + +APPLICATION PROCESS - An application process is an object executing in a + real system (computer). + +APPLICATION SERVICE ELEMENT - An application service element (ASE) is + the building block of an application entity (AE). Each AE consists + of one or more service elements, as defined by its application + context. + +ASE - See APPLICATION SERVICE ELEMENT. + +ATTRIBUTE - An attribute is the information of a particular type + concerning an object and appearing in an entry describing that + object in the Directory Information base (DIB). + +ATTRIBUTE TYPE - An attribute type is that component of an attribute + which indicates the class of information given by that attribute. + +ATTRIBUTE VALUE - An attribute value is a particular instance of the + class of information indicated by an attribute type. + +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. + + + + +ESCC X.500/X.400 Task Force [Page 41] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + +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. + + + + +ESCC X.500/X.400 Task Force [Page 42] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + +DIRECTORY USER AGENT - A Directory User Agent (DUA) is an OSI + application process which represents the user in accessing the + Directory. + +DISTINGUISHED NAME - The distinguished name of a given object is the + sequence of relative distinguished names (RDNs) of an entry which + represents the object and those of all of its superior entries (in + descending order). + +DIT - See DIRECTORY INFORMATION TREE. + +DMD - See DIRECTORY MANAGEMENT DOMAIN. + +DN - See DISTINGUISHED NAME. + +DNS - See DOMAIN NAME SERVICE. + +DOMAIN NAME SERVICE - A hierarchical, distributed naming service + currently used in the Internet. DNS names typically take the form + of <machine.site.domain>, where <.domain> may be ".COM", ".EDU", + ".GOV", ".MIL", ".NET", ".ORG" or ".<country-code>". + +DSA - See DIRECTORY SYSTEM AGENT. + +DSP - See DIRECTORY SYSTEM PROTOCOL. + +DUA - See DIRECTORY USER AGENT. + +ENCODED INFORMATION TYPE - It is the code and format of information that + appears in the body of an IP-message (examples of coded information + types are Telex, TIFO (Group 4 Facsimile), and voice). + +ENVELOPE - A place in which the information to be used in the + submission, delivery and relaying of a message is contained. + +FIPS - Federal Information Processing Standard. FIPS are produced by + NIST and specify a standard for the federal government, most FIPS + reference other formal standards from ANSI, IEEE, ISO or CCITT. + +GOSIP - The Government Open System Interconnection (OSI) Profile. GOSIP + is a FIPS which defines the elements of OSI to be required by + government purchasers and how those elements should be implemented. + GOSIP is based on OSI standards and OIW implementor's agreements. + +HEADING - The heading of an IP-message is the control information that + characterizes an IP-message. + +INTERPERSONAL MESSAGING - Interpersonal Messaging (IPM) is communication + + + +ESCC X.500/X.400 Task Force [Page 43] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + between persons by exchanging messages. + +INTERPERSONAL MESSAGING SERVICE - The set of service elements which + enable users to exchange interpersonal messages. + +INTERPERSONAL MESSAGING SYSTEM - An Interpersonal Messaging System + (IPMS) is the collection of User Agents (UAs) and Message Transfer + Agents (MTAs), which provide the Interpersonal Messaging Service. + +IP - A non-OSI network protocol, the Internet Protocol, used extensively + in the Internet. CLNP is the OSI alternative to IP. + +IP-MESSAGE - An IP-message carries information generated by and + transferred between Interpersonal Messaging (IPM) User Agents + (UAs). An IP-message contains a Heading and a Body. + +IPM - See INTERPERSONAL MESSAGING. + +IPM-STATUS-REPORT - The pieces of information generated by an + Interpersonal Messaging (IPM) User Agent Entity (UAE) and + transferred to another IPM UAE, either to be used by that UAE or to + be conveyed to the user. + +IPMS - See INTERPERSONAL MESSAGING SYSTEM. + +ISO - An international standards making organization which, among other + things, develops OSI standards. + +MANAGEMENT DOMAIN - The set of Message Handling System (MHS) entities + managed by an Administration or organization that includes at least + one Message Transfer Agent (MTA). + +MD - See MANAGEMENT DOMAIN. + +MESSAGE - In the context of Message Handling Systems (MHSs), the unit of + information transferred by the Message Transfer System (MTS). It + consists of an envelope and a content. + +MESSAGE HANDLING ADDRESS - An Originator/Recipient (O/R) address which + is comprised of an Administrative Management Domain (ADMD), a + country name, and a set of user attributes. + +MESSAGE HANDLING SYSTEM - The set of User Agents (UAs) plus the Message + Transfer System (MTS). + +MESSAGE TRANSFER AGENT - The functional component that, together with + the other Message Transfer Agents (MTAs), constitutes the Message + Transfer System (MTS). The MTAs provide message transfer service + + + +ESCC X.500/X.400 Task Force [Page 44] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + 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 + + + +ESCC X.500/X.400 Task Force [Page 45] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + all other objects. A name must be unambiguous (i.e. denote just + one object); however, it need not be unique (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. + + + +ESCC X.500/X.400 Task Force [Page 46] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + +PRIVATE DIRECTORY MANAGEMENT DOMAIN - A Private Directory Management + Domain (PRDMD) is a Directory Management Domain which is managed by + an organization other than an administration. + +PRIVATE MANAGEMENT DOMAIN - A Private Management Domain (PRMD) is a + management domain managed by a company or non-commercial + organization. + +PRMD - See PRIVATE MANAGEMENT DOMAIN. + +RDN - See RELATIVE DISTINGUISHED NAME. + +RECIPIENT - A user, a human being or computer process, who receives a + message from the Message Handling System (MHS). + +RECIPIENT USER AGENT - A User Agent (UA) to which a message is delivered + or that is specified for delivery. + +REFERRAL - A referral is an outcome which can be returned by a Directory + System Agent (DSA) which cannot perform an operation itself, and + which identifies one or more other DSAs more able to perform the + operation. + +RELATIVE DISTINGUISHED NAME - A Relative Distinguished Name (RDN) is a + set of attribute value assertions, each of which is true, + concerning the distinguished values of a particular entry. + +RELAYING - The interaction by which one Message Transfer Agent (MTA) + transfers to another MTA the content of a message plus the relaying + envelope. + +RELAYING ENVELOPE - The envelope which contains the information related + to the operation of the Message Transfer System (MTS) plus the + service elements requested by the originating User Agent (UA). + +RFC - Request for Comments. The RFC's are documents used to propose or + specify internet community standards. + +ROOT - The vertex that is not the final vertex of any arc is referred to + as the root vertex (or informally as the root) of the tree. + +SCHEMA - The Directory Schema is the set of rules and constraints + concerning the Directory Information Tree (DIT) structure, object + class definitions, attribute types, and syntaxes which characterize + the Directory Information base (DIB). + +SDE - See SUBMISSION AND DELIVERY ENTITY. + + + + +ESCC X.500/X.400 Task Force [Page 47] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + +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 + + + +ESCC X.500/X.400 Task Force [Page 48] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + processes (for example, an editor, a file system, a word processor) + that are used to create, inspect, and manage the storage of + messages. There is typically one user per User Agent (UA). During + message preparation, the originator communicates with his UA via an + input/output (I/O) device (for example, a keyboard, display, + printer, facsimile machine, and/or telephone). Also by means of + these devices, the UA communicates to its user messages received + from the Message Transfer System (MTS). To send and receive + messages, the UA interacts with the MTS via the submission and + delivery protocol. + +USER AGENT ENTITY - A User Agent Entity (UAE) is an entity in the User + Agent Layer (UAL) of the Application Layer that controls the + protocol associated with cooperating UAL services. It exchanges + control information with the Message Transfer Agent Entity (MTAE) + or the Submission and Delivery Entity (SDE) in the layer below. + The control information is the information the Message Transfer + layer (MTL) requires to create the appropriate envelope and thus + provide the desired message transfer service elements. + +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 + + + +ESCC X.500/X.400 Task Force [Page 49] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + implementations or transport protocols. + + DISI is an offshoot of the OSI Directory Services group, and, + accordingly, is a combined effort of the OSI Integration Area and + User Services Area of the IETF. The current OSIDS working group was + chartered to smooth out technical differences in information storage + schema and difficulties in the interoperability and coherence of + various X.500 implementations. The DISI group is concerned solely + with expanding the Directory Services infrastructure. As DISI will + be providing information to facilitate the building of infrastructure + with an eye towards truly operational status, DISI will need to form + liaisons with COSINE, PARADISE, and perhaps the RARE WG3. + + As a final document, the DISI working group shall write a charter for + a new working group concerned with user services, integration, + maintenance and operations of Directory Services, the Operations and + Infrastructure of Directory Services (OIDS) Group. + + One particular DISI document you may be interested in is a catalogue + of the various X.500 implementations: + + Title : Catalog of Available X.500 Implementations + Author(s) : R. Lang, R. Wright + Filename : rfc1292.txt + Pages : 103 + + This document is available on the ESnet Information Server in the + [ANONYMOUS.RFCS] directory. + + Mailing list address: + General Discussion: disi@merit.edu + To Subscribe: disi-request@merit.edu + Anonymous FTP site address: (e-mail archive is here) + merit.edu + + IETF OSI-DS (OSI Directory Service Working Group) + + The OSI-DS group works on issues relating to building an OSI + Directory Service using X.500 and its deployment on the Internet. + Whilst this group is not directly concerned with piloting, the focus + is practical, and technical work needed as a pre-requisite to + deployment of an open Directory will be considered. + + The major goal of this WG is to provide the technical framework for a + Directory Service infrastructure on the Internet. This + infrastructure should be based on the OSI Directory (X.500). It is + intended that this infrastructure can be used by many applications. + Whilst this WG is not directly concerned with operation of services, + + + +ESCC X.500/X.400 Task Force [Page 50] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + close liaison is expected with those groups which do operate pilots + and services. + + Liaisons have been established with RARE WG3, NIST, CCITT/ISO IEC, + North American Directory Forum. + + X.500 (1984) / ISO 9594 does not have sufficient functionality for + full deployment on the Internet. This group identifies areas where + extensions are required. + + It is a basic aim of the group to be aligned to appropriate base + standards and functional standards. Any activity should be + undertaken in the light of ongoing standardization activity. Areas + which should be examined include: + + o Replication + + o Knowledge Representation + + o Schema Management + + o Access Control + + o Authentication + + o Distributed operations for partially connected DSAs + + o Presentation Address Handling + + Mailing list address: + General Discussion: osi-ds@cs.ucl.ac.uk + To Subscribe: osi-ds-request@cs.ucl.ac.uk + Anonymous FTP site address: (all OSI-DS documents and e-mail archive + cs.ucl.ac.uk are here) + + FOX (Field Operational X.500 Project) + + The FOX project is a DARPA funded effort to provide a basis for + operational X.500 deployment in the NREN/Internet. This work is + being carried out at Merit, NYSERnet/PSI, SRI and ISI. ISI is the + main contractor and responsible for project oversight. + + There are two primary thrusts of the FOX project: + + 1. X.500 Infrastructure: It is important that multiple + interoperable platforms be available for deployment. FOX + plans to examine and test the interoperability of the QUIPU + and NIST-X.500 (Custos) implementations, and DNANS-X.500 if + + + +ESCC X.500/X.400 Task Force [Page 51] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + 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 + + + +ESCC X.500/X.400 Task Force [Page 52] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + likely be ASCII-ized and published as an informational RFC. + + NIST (National Institute of Standards and Technology) + + NIST is involved in several X.500 activities: standards, pilot + deployment, and development of an X.500 implementation, Custos. 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 + + + +ESCC X.500/X.400 Task Force [Page 53] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + through international discussions and liaison activities. + + The Directory SIG of the Workshop produces agreements on the + implementation of Directory protocols based on ISO 9594 and CCITT + X.500 Recommendations. There are three major areas that the SIG is + working on for 1991: access control, replication, and distributed + operations. + + Mailing list address: + General Discussion: dssig@nisc.sri.com + To Subscribe: dssig-request@nisc.sri.com + + PARADISE Project + + The PARADISE project is based at the Department of Computer Science, + University College London (UCL). + + PARADISE is a sub-project of the broader COSINE project sponsored + under the umbrella of EUREKA by eighteen participating countries and + aimed at promoting OSI to the academic, industrial and governmental + research and development organizations in Europe. The countries + involved are those of the EC, EFTA plus Yugoslavia; that is: + Austria, Belgium, Denmark, Finland, France, Germany, Greece, Holland, + Ireland, Italy, Luxembourg, Norway, Portugal, Spain, Sweden, + Switzerland, United Kingdom, and Yugoslavia. + + The partners funded by PARADISE besides UCL are: + + o The Networks Group at the University of London Computer Centre + (ULCC), which is a service-oriented organization providing a + range of facilities to the academic community in London and the + entry point into the UK for IXI, the COSINE international X.25 + backbone; + + o X-Tel Services Ltd, a software company based in Nottingham + which currently provides service support to the UK Academic + X.500 pilot; and + + o PTT Telematic Systems from the Netherlands, which in turn has + subcontracted the Swiss and Finnish PTTs, and whose involvement + is to create a forum for discussion on X.500 among the European + carrier administrations. + + The project also aims to have representation from all the + participating countries, which in the majority of cases are the + existing X.500 national pilots. + + Of the 18 countries involved, at least 12 are registered in the White + + + +ESCC X.500/X.400 Task Force [Page 54] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + Pages Pilot Project. Most countries are using the QUIPU + implementation developed at UCL. However, a French group has + developed PIZARRO, which will form the basis of the emerging French + pilot. In Italy, a Torino-based company Systems Wizards are using + DirWiz, which is currently the sole representative from Italy in the + tree. + + Mailing list address: + helpdesk@paradise.ulcc.ac.uk + + PSI White Pages Pilot Project + + The White Pages Pilot Project is the first production-quality field + test of the OSI Directory (X.500). The pilot currently has a few + hundred organizations (more each month) and is based on OSI TP4 over + TCP/IP (RFC-1006). + + Anonymous FTP site address: (Most X.500 pilot project software is + uu.psi.com here as well as more information) + + ANSI ASC X3T5.4 (Directory Ad Hoc Group) + + The American National Standards Institute (ANSI) Accredited Standards + Committee (ASC) X3T5.4. This group reviews the Proposed Draft + Amendments (PDAMs) for extensions to the International Consultative + Committee for Telegraphy and Telephony (CCITT) X.500 + Recommendations/International Organization for Standardization + (ISO)/International Electrotechnical Commission (IEC) 9594. + +Appendix B: Current Activities in X.400 + + NOTE: The following are edited excerpts from the IETF X.400 Services + Monthly reports as well as a few IETF scope documents. Effort has + been taken to make sure this information is current as of February + 1992. At the end of each section are lists of anonymous FTP and/or + an e-mail address if more information is desired. + + IETF OSIX400 (IETF OSI X.400 Working Group) + + The IETF OSI X.400 Working Group is chartered to identify and provide + solutions for problems encountered when operating X.400 in a dual + protocol internet. This charter includes pure X.400 operational + issues as well as X.400 <-> RFC 822 gateway (ala RFC 987) issues. + + Mailing list address: + General Discussion: ietf-osi-x400@cs.wisc.edu + To Subscribe: ietf-osi-x400-request@cs.wisc.edu + + + + +ESCC X.500/X.400 Task Force [Page 55] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + 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: ietf-osi-x400ops@pilot.cs.wisc.edu + To Subscribe: ietf-osi-x400ops-request@pilot.cs.wisc.edu + + 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: mhs-ds@mercury.udev.cdc.com + To Subscribe: mhs-ds-request@mercury.udev.cdc.com + 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 + + + +ESCC X.500/X.400 Task Force [Page 56] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + running an X.400 Message Transfer Agent (MTA) which is connected to + U.S. and international MTAs using RFC1006/TCP/IP. Internet sites are + invited to join our PRMD or establish X.400 connections with us. The + organizational work is being done jointly by IETF working groups and + RARE Working Group 1. + + Mailing list address: + General Discussion: x400-project-team@cs.wisc.edu + + 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 + + + +ESCC X.500/X.400 Task Force [Page 57] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + 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 + + + +ESCC X.500/X.400 Task Force [Page 58] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + contains implementations of the 1984 X.400 versions of ROS and + RTS. + + o Although the ISODE is not "supported" per se, it does have a + problem reporting address, Bug-ISODE@XTEL.CO.UK. Bug reports + (and fixes) are welcome by the way. + + o The discussion group ISODE@NISC.SRI.COM is used as an open + forum on ISODE. Contact ISODE-Request@NISC.SRI.COM to be added + to this list. + + o The primary documentation for this release consists of a five + volume User's Manual (approx. 1000 pages) and a set of UNIX + manual pages. The sources to the User's Manual are in LaTeX + format. In addition, there are a number of notes, papers, and + presentations included in the documentation set, again in + either LaTeX or SLiTeX format. If you do not have LaTeX, you + should probably get a hardcopy from one of the distribution + sites below. + + ISODE/QUIPU Distribution Sites + + The FTP or FTAM distributions of ISODE-7.0 consists of 3 files. 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 + + + +ESCC X.500/X.400 Task Force [Page 59] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + want to retrieve pilot-ps.tar.Z again also, as it contains an updated + Administrator Guide. + + Note that the wpp-addon.tar.Z file needs to be installed on top of + the ISODE 7.0 distribution; it does not duplicate any of the ISODE + 7.0, you need to retrieve and generate that too. + + PP 6.0 + + PP is a Message Transfer Agent, intended for high volume message + switching, protocol conversion, and format conversion. It is + targeted for use in an operational environment, but is also be useful + for investigating message related applications. Good management + features are a major aspect of this system. PP supports the 1984 and + 1988 versions of the CCITT X.400 / ISO 10021 services and protocols. + Many existing RFC-822 based protocols are supported, along with RFC- + 1148bis conversion to X.400. PP is an appropriate replacement for + MMDF or Sendmail. This is the second public release of PP, and + includes substantial changes based on feedback from using PP on many + sites. + + o PP is not proprietary and can be used for any purpose. The only + restriction is that suing of the authors for any damage the + code may cause is not allowed. + + o PP runs on a range of UNIX and UNIX-like operating systems, + including SUNOS, Ultrix, and BSD. A full list of platforms on + which PP is know to run is included in the distribution. + + o 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. + + + +ESCC X.500/X.400 Task Force [Page 60] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + - 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: PP-SUPPORT@CS.UCL.AC.UK + X.400: S=PP-Support; OU=CS; O=UCL; + PRMD=UK.AC; ADMD= ; C=GB; + + o The discussion group PP-PEOPLE@CS.UCL.AC.UK is used as an open + forum on PP; Contact PP-PEOPLE-REQUEST@CS.UCL.AC.UK to be added + to this list. + + + + +ESCC X.500/X.400 Task Force [Page 61] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + o The primary documentation for this release consists of a three + and a half volume User's Manual (approx. 300 pages) and a set + of UNIX manual pages. The sources to the User's Manual are in + LaTeX format. + + PP Distribution Sites + + If you can FTP to the Internet from outside Europe, then use + anonymous FTP to uu.psi.com [136.161.128.3] to retrieve the file pp- + 6.tar.Z in binary mode from the ISODE/ directory. This file is the + tar image after being run through the compress program and is + approximately 3Mb in size. + + If you can FTP to the Internet from Europe, then use anonymous FTP to + archive.eu.net [192.16.202.1] to retrieve the file pp-6.tar.Z in + binary mode from the network/ISODE/ directory. This file is the tar + image after being run through the compress program and is + approximately 3Mb in size. + + 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 + + + +ESCC X.500/X.400 Task Force [Page 62] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + 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 + -------------------------------------------------------------------- + + + +ESCC X.500/X.400 Task Force [Page 63] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + 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 bug-ISODE@xtel.co.uk. 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 + + + + +ESCC X.500/X.400 Task Force [Page 64] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + 16. Only QUIPU tested, built using BSD43 config + + 17. Need bug-fix no. 6 from bug-ISODE@xtel.co.uk + + 18. Built using BSD config, no VT or SNMP + + The above tables do not refer to beta releases of ISODE and PP more + recent than the public ISODE-7.0 or PP-5.2 releases. The above table + is generated from reports sent to bug-ISODE and pp-support. There is + no guarantee the information is correct. + +Appendix D: Sample X.500 Input File and Restricted Character List + + Below is a sample datafile that illustrates the format for providing + data about persons at your site to be loaded into the ESnet DSA. + Following the sample datafile is a detailed explanation of the format + and content of the file. We have tried to be as flexible as possible + in defining the format of the file, given the constraints imposed by + an automated process. We would appreciate feedback on the format of + the file and will try to accommodate any specific needs you may have + to any extent that is reasonable. + + # + # Sample Data File for Bulk Loading X.500 Database + # + # delimiter character is "," 1 + # field 1 is commonName 2 + # field 2 is phone extension 3 + # area code for all numbers is 510 4 + # prefix for all numbers is 422 5 + # field 3 is rfc822Mailbox 6 + # field 4 is facsimileTelephoneNumber 7 + # default facsimileTelephoneNumber is (510) 422-3333 8 + # postalAddress for all entries is: 9 + # National Energy Research Supercomputer Center 10 + # P.O. Box 5509 11 + # Livermore, California 94552 12 + # + Chris Anderson,1915,anderson@ws1.nersc.gov, 13 + Lila Brown,5680,brownl@ws2.nersc.gov, 14 + Bob Green,4474,, 15 + Max Jones,4488,elvis@presley.nersc.gov,5104224444 16 + Dave Smith,9818,smithd@ws3.nersc.gov, 17 + Cathy White,4016,snow@white.nersc.gov, 18 + <end-of-file> + + Comment lines at the beginning of the file convey relevant formatting + information. + + + +ESCC X.500/X.400 Task Force [Page 65] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + Following comment lines, each data line contains information about + one person. + + Fields within a single data line are separated by a delimiter + character. You specify the delimiter character you wish to use in + the comment section; be sure to choose a delimiter which does not + appear as a legitimate character in any field of a data line. + + You may provide all or part of the attribute types listed in the + table in Section 2.5 (commonName is required). In the comment + section, you must indicate which attribute types are contained in + each field of a data line. + + Each data line must contain the same number of fields and the same + order of fields (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 + + + +ESCC X.500/X.400 Task Force [Page 66] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + applies to all entries. + + Line 13 commonName= Chris Anderson + surName= Anderson + telephoneNumber= 510-422-1915 + rfc822MailBox= anderson@ws1.nersc.gov + 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= brownl@ws2.nersc.gov + 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= elvis@presley.nersc.gov + 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= smithd@ws3.nersc.gov + facsimileTelephoneNumber= 510-422-3333 + postalAddress= National Energy Research Supercomputer Center + P.O. Box 5509 + Livermore, California 94552 + + + + + +ESCC X.500/X.400 Task Force [Page 67] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + Line 18 commonName= Cathy White + surName= White + telephoneNumber= 510-422-4016 + rfc822MailBox= snow@white.nersc.gov + 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 + + + + +ESCC X.500/X.400 Task Force [Page 68] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + 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 + + + +ESCC X.500/X.400 Task Force [Page 69] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + 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 + + + + +ESCC X.500/X.400 Task Force [Page 70] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + 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 + + + + +ESCC X.500/X.400 Task Force [Page 71] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + 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 + + + + + +ESCC X.500/X.400 Task Force [Page 72] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + 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 + + + +ESCC X.500/X.400 Task Force [Page 73] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + 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 + + + + + + + +ESCC X.500/X.400 Task Force [Page 74] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + 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 + + + + + + + + + +ESCC X.500/X.400 Task Force [Page 75] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + 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 + + + + +ESCC X.500/X.400 Task Force [Page 76] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + +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) + + + + +ESCC X.500/X.400 Task Force [Page 77] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + +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 + + + +ESCC X.500/X.400 Task Force [Page 78] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + Internet, making use of the X.500 protocols and services. This + document summarizes the strategy established by the Working Group, + and describes a number of RFCs which will be written in order to + establish the technical framework. + +"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 + + + +ESCC X.500/X.400 Task Force [Page 79] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + Contacts and some limited network information in the Directory + would be immediately useful and would also provide the preliminary + framework for some distributed NIC functions. This paper describes + the interim schema used to contain this information. + +"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. + + + + +ESCC X.500/X.400 Task Force [Page 80] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + +"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 + + + +ESCC X.500/X.400 Task Force [Page 81] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + account the variety of existing large transport networks, there is + now the chance of implementing a worldwide message handling service + using the same electronic mail standard and therefore without the + need of gateways with service reduction and without the restriction + to a single common transport network. This document proposes how + messages can travel over different networks by using multi stack + MTAs as relays. Document formats and coordination procedures bridge + the gap until an X.500 directory service is ready to store the + needed connectivity and routing information. + + International Standards Documents + +International Consultative Committee for Telephone and Telegraph. Open + Systems Interconnection - The Directory. X.500 Series + Recommendations. December, 1988. + + (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]. + + + + +ESCC X.500/X.400 Task Force [Page 82] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + +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: raiken@nsf.gov + + + + +ESCC X.500/X.400 Task Force [Page 83] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + Joe Carlson + Lawrence Livermore National Laboratory + Livermore, California USA + Email: carlson@lll-winken.llnl.gov + + Les Cottrell + Stanford Linear Accelerator Center + Menlo Park, California USA + Email: cottrell@slacvm.slac.stanford.edu + + Tim Doody + Fermi National Accelerator Laboratory + Batavia, Illinois USA + Email: doody@fndcd.fnal.gov + + Tony Genovese (Contributing Author) + Lawrence Livermore National Laboratory + Livermore, California USA + Email: genovese@es.net + + Arlene Getchell (Contributing Author) + Lawrence Livermore National Laboratory + Livermore, California USA + Email: getchell@es.net + + Charles Granieri + Stanford Linear Accelerator Center + Menlo Park, California USA + Email: cxg@slacvm.slac.stanford.edu + + Kipp Kippenhan (Contributing Author) + Fermi National Accelerator Laboratory + Batavia, Illinois USA + Email: kippenhan@fnal.fnal.gov + + Connie Logg + Stanford Linear Accelerator Center + Menlo Park, California USA + Email: cal@slacvm.slac.stanford.edu + + Glenn Michel + Los Alamos National Laboratory + Los Alamos, New Mexico USA + Email: gym@lanl.gov + + Peter Mierswa + Digital Equipment Corporation USA + + + + +ESCC X.500/X.400 Task Force [Page 84] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + Jean-Noel Moyne + Lawrence Berkeley Laboratory + Berkeley, California USA + Email: jnmoyne@lbl.gov + + Kevin Oberman (Contributing Author) + Lawrence Livermore National Laboratory + Livermore, California USA + Email: oberman@icdc.llnl.gov + + Dave Oran + Digital Equipment Corporation USA + + Bob Segrest + Digital Equipment Corporation USA + + Tim Streater + Stanford Linear Accelerator Center + Menlo Park, California USA + Email: streater@slacvm.slac.stanford.edu + + Allen Sturtevant (Chair, Contributing Author, Document Editor) + Lawrence Livermore National Laboratory + Livermore, California USA + Email: sturtevant@es.net + + Mike Sullenberger + Stanford Linear Accelerator Center + Menlo Park, California USA + Email: mls@scsw5.slac.stanford.edu + + Alan Turner (Contributing Author) + Pacific Northwest Laboratory + Richland, Washington USA + Email: ae_turner@pnl.gov + + Linda Winkler (Contributing Author) + Argonne National Laboratory + Argonne, Illinois USA + Email: b32357@anlvm.ctd.anl.gov + + Russ Wright (Contributing Author) + Lawrence Berkeley Laboratory + Berkeley, California USA + Email: wright@lbl.gov + + + + + + +ESCC X.500/X.400 Task Force [Page 85] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + +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: sturtevant@es.net + + + Tony Genovese + Lawrence Livermore National Laboratory + P.O. Box 5509; L-561 + Livermore, CA 94551 + + Phone: +1 510-423-2471 + Email: genovese@es.net + + + Arlene Getchell + Lawrence Livermore National Laboratory + P.O. Box 5509; L-561 + Livermore, CA 94551 + + Phone: +1 510-423-6349 + Email: getchell@es.net + + + 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: kippenhan@fnal.fnal.gov + + + + + + + + + +ESCC X.500/X.400 Task Force [Page 86] + +RFC 1330 X.500 and X.400 Plans for ESnet May 1992 + + + Kevin Oberman + Lawrence Livermore National Laboratory + P.O. Box 5509; L-156 + Livermore, CA 94551 + + Phone: +1 510-422-6955 + Email: oberman1@llnl.gov + + + Alan Turner + Pacific Northwest Laboratory + P.O. Box 999; K7-57 + Richland, WA 99352 + + Phone: +1 509-375-6670 + Email: ae_turner@pnl.gov + + + Linda Winkler + Argonne National Laboratory + 9700 South Cass Avenue + Building 221 B251 + Argonne, IL 60439 + + Phone: +1 708-252-7236 + Email: lwinkler@anl.gov + + + Russ Wright + Lawrence Berkeley Laboratory + 1 Cyclotron Road + MS 50B-2258 + Berkeley, CA 94720 + + Phone: +1 510-486-6965 + Email: wright@lbl.gov + + + + + + + + + + + + + + + +ESCC X.500/X.400 Task Force [Page 87] +
\ No newline at end of file |