RFC 1330
Recommendations for the Phase I Deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESNET Community
Recommendations for the Phase I Deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESnet Community 🎀
Okay bestie, this is RFC 1330 💖, published in May 1992 in the Network Working Group series. The authors are the ESCC X.500/X.400 Task Force, which belongs to the ESnet Site Coordinating Committee (ESCC) at the Energy Sciences Network (ESnet) 🌸. The underlying whitepaper is Version 1.1, from March 1992 ✨. The header doesn't list anything it obsoletes or updates, so it isn't replacing or changing any other RFC 💅.
Status of this Memo
Quick legal-ish bit 📜: this memo is here to provide information for the Internet community. It is not an Internet standard. Distribution is unlimited, so share it with your bestie 🫶.
Overview
Okay so ESnet is a nation-wide computer data communications network 🌐. It's managed and funded by the United States Department of Energy, Office of Energy Research (U.S. DOE/OER), and its whole purpose is supporting multiple program, open scientific research 🔬. The big goals are helping people reach major Energy Research (ER) scientific facilities remotely, spreading information between scientific collaborators across every ER program, and giving widespread access to existing ER supercomputer facilities 💻. Iconic energy 😭.
Coordination of ER-wide network-related technical activities over the ESnet backbone happens through the ESnet Site Coordinating Committee (ESCC) 👑. The committee has one technical contact person from each backbone site, plus some members of the ESnet management and networking staff. Whenever a new level of ESnet service is needed, the ESCC usually creates a task force to dig into the issue 🔍. Each task force usually ends up writing a whitepaper, which makes recommendations to the ESnet community on how those services should be deployed to meet the DOE/OER mission 🦋.
This RFC is a near verbatim copy of the whitepaper written by the ESnet Site Coordinating Committee's X.500/X.400 Task Force ✨.
Table of Contents
Status of this Document ....................................... 4
Acknowledgments ............................................... 4
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
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 ............................................ 86Status 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 🌈. You can grab it with anonymous FTP from 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 🍓. Distribution is unlimited 💜.
Acknowledgments
Huge shoutout to everyone who joined the ESCC X.500/X.400 Task Force 🫶. Several of them also wrote parts of this document, and you can find more info about the task force members and contributing authors in Appendix H 🧚.
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 Laboratory1. Introduction ✨
Introduction incoming, it's about to get good 🌈
1.1. Abstract and Introduction ✨
Okay bestie, this doc is basically a starter plan 🎀 for rolling out OSI Directory Services (X.500) and OSI Message Handling Services (X.400) in Phase I across the ESnet community. The directly connected ESnet backbone sites are expected to join in and follow the suggestions here 🫶.
Section 7 of the "ESnet Program Plan" (DOE/OER-0486T, dated March 1991) calls out the need for more research and investigation into electronic mail and directory services 📬. That's the whole reason the ESCC X.500/X.400 Task Force exists 💅. The task force is also working on a coordinated, interoperable deployment of OSI Directory Services and OSI Message Handling across the ENTIRE ESnet community 🌍. Only a small subset of people is actively doing this stuff right now, so considerable effort must be made to build the "base" 🧱. If directly connected ESnet sites participate, there'll be a consistent transition path and the services will be mutually valuable and useful 🦋.
X.500 and X.400 are constantly evolving standards, and they usually get updated every four years 🔄. U.S. GOSIP (Government OSI Profile) Requirements get updated to define extra functionality the U.S. Federal Government needs, usually every two years 🏛️. As X.500 and X.400 evolve and the GOSIP Requirements get extended, consideration must be given to how that affects the existing services in the ESnet community 🤔. At these crossroads, or when a sizeable jump in service functionality is wanted, another "phase of deployment" may be in order 🛣️. Honestly, there isn't one specific "final phase" goal 🙅. It's more like several new releases (updates) to the level of existing services ✨.
1.2. Structure of this Document
X.500 comes first 📚. The issues covered there are 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.
In the X.400 section 📨, we get into MTA (Message Transfer Agent) deployment, ESnet X.400 well-known entry points, ESnet backbone site X.400 well-known entry points, MTA registration, naming hierarchy, PRMD peering, bidirectional X.400-SMTP relaying and private/commercial X.400 routing.
Last but not least 💖, we talk about name registration with ANSI (American National Standards Institute), GSA (General Services Administration) and the U.S. Department of Commerce, Patent and Trademark Office (PTO).
2. X.500 - OSI Directory Services 📖
2.1. Brief Tutorial
X.500 is a CCITT/ISO standard that defines a global solution for distributing and retrieving information (the directory service) 🌐. It comes with some major vibes: decentralized management, powerful searching capabilities, a single global namespace and a structured framework for storing information 💜. The 1988 version specifies four models for the Directory Service: the Information Model, the Functional Model, the Organizational Model and the Security Model. And because that's just how international standards go, work is still continuing on the 1992 X.500 standard agreements 🌸.
The Information Model is all about how information is defined in the directory 🗂️. The Directory holds information objects, which contain info about "interesting" objects in the real world. These objects are modeled as entries in an information base called the Directory Information Base (DIB). Each entry holds information about one object, ie, a person, a network or an organization 🧑💻. An entry is built from a set of attributes, and each attribute holds a single piece of information about the object. For example, a person's entry might include surname, telephoneNumber, postalAddress, rfc822Mailbox (SMTP mail address), mhsORAddresses (X.400 mail address) and facsimileTelephoneNumber 📇. Each attribute has an attribute syntax that describes the data it contains, like an alphanumeric string or photo data 📸. The OSI Directory is extensible, so it defines several common types of objects and attributes and lets you define new ones as new applications come along that use the Directory 🧩.
Directory entries are arranged in a hierarchical structure called the Directory Information Tree (DIT) 🌳. This structure is what's used to uniquely name entries. The name of an entry is its Distinguished Name (DN) 🏷️. It's formed by taking the DN of the parent's entry and adding the Relative Distinguished Name (RDN) of the entry. Along the path, the RDNs are collected, each one naming an arc in the path. So a DN for an entry is built by tracing the path from the root of the DIT down to the entry 🛤️.
The Functional Model defines how information is stored in the directory and how users access it 🔑. It has two components. The first is the Directory User Agent (DUA), an application process that interacts with the Directory on behalf of the user. The second is 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 describes the service in terms of the policy defined between entities and the information they hold 🤝. It defines how portions of the DIT map onto DSAs. A Directory Management Domain (DMD) consists of one or more DSAs, which together 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 get 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 📋. Several of those 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. Here are the combined totals for all of these countries (including the United States) as of December 1991 📊:
DSAs: 301
Organizations: 2,132
White Pages Entries: 581,104With all that national and international connectivity inside 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
Okay, real talk 😬: interoperability testing has not been performed on most X.500 implementations. On top of that, some X.500 functions aren't mature standards yet, and implementors often add them as noninteroperable extensions 🙈.
To keep things interoperable across the entire ESnet community, the University College London's publicly available X.500 implementation (QUIPU) is recommended 🎀. It's known to run on several UNIX-derivative platforms and operates over CLNS and RFC-1006 (with RFC-1006 being the currently recommended stack) 🧩. It's also 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 of deployment for X.500 services in the ESnet community will recommend products (either commercial or public domain) that pass conformance and interoperability tests 🔜.
2.4. Naming Structure
As participants in the PSI White Pages Pilot Project, ESnet backbone sites will line up with the naming structure the Pilot uses 🗺️. This structure is based on a naming scheme for the US portion of the DIT that was developed by the North American Directory Forum (NADF) and documented in RFC-1255 📘. With this scheme, an organization with national standing gets listed directly under the US node in the global DIT 🇺🇸. Organizations chartered by the U.S. Congress, as well as organizations that have alphanumeric nameforms registered with ANSI, are said to have national standing. So a backbone site that's a national laboratory would be listed under country=US, like this:
@c=US@o=Lawrence Livermore National LaboratoryA site with an ANSI-registered organization name gets listed the same way:
@c=US@o=National Energy Research Supercomputer CenterA university gets listed below the state it's located in 🎓:
@c=US@st=Florida@o=Florida State UniversityA commercial entity gets listed under the city or state where it's doing business, or under "Doing Business As", depending on where its DBA is registered 💼:
@c=US@st=California@o=General Atomics
(or)
@c=US@st=California@l=San Diego@o=General AtomicsA list of the current ESnet backbone sites, and their locations, is provided in Appendix E 📍.
Directly connected ESnet backbone sites will be responsible for administering the objects that reside below their respective portions of the DIT 🗝️. Basically, they must provide their own "Name Registration Authority". I know that sounds like a lot, but it's really just setting up a procedure for naming that makes sure duplicate entries don't pop up 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". That would show up in the DIT as:
@c=US@st=Massachusetts@o=MIT@ou=Computer ScienceSimilarly, all the other names created under "@c=US@st=Massachusetts@o=MIT" would be administered by that same MIT Name Registration Authority. This keeps every Organizational Unit under "@c=US@st=Massachusetts@o=MIT" unique 🙌. By default, each ESnet Site Coordinator is assumed to be the Name Registration Official for their respective site 👑. If an ESnet Site Coordinator doesn't want to act in that capacity, they can designate another individual at their site as the Name Registration Official 💅.
2.4.1. Implications of the Adoption of RFC-1255 by PSI ✨
okay so the North American Directory Forum (NADF) is a crew of commercial vendors who want to offer commercial X.500 Directory Services 💼. They've put out several documents since they formed, and the juiciest ones 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 like this:
"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."
So National Laboratories (e.g. LBL, LLNL) look like they count as organizations with national-standing 🔬. The ESnet backbone sites that aren't National Labs may wish to register with ANSI to get their organization listed directly under c=US, but only if that's actually what they want 🤷♀️. It's super important to note that NADF is not a registration authority. It's a group of service providers setting rules for information sharing and mutual interoperability in a commercial environment 🚫.
For more on registering with ANSI, GSA or the U.S. Patent and Trademark office, check out Section 4 of this document. For more on PSI, see Appendix A 🦋.
2.4.2. Universities and Commercial Entities 🎓
Several ESnet backbone sites aren't National Labs (e.g. CIT, FSU, GA, ISU, MIT, NYU, UCLA and UTA). Usually at these places, a small group of researchers is doing DOE/OER funded research. So that group might not adequately represent the whole X.500 community at their facility 🥺. Plus, ESnet Site Coordinators at these facilities might not be authorized to act as the Name Registration Official for their site 😬. So the question is, how do these sites take part in the recommended Phase I deployment of ESnet X.500 services? There are two possible solutions for this dilemma 💅:
- If the site isn't 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, it would be prudent for the Site Coordinator to notify or seek approval from some responsible entity. Once the site wants 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. - 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 that 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 manager will probably want to get input from others within the organization before deciding how to structure the local DIT 🧠.
Some organizations currently taking part in the Pilot have set up a simple structure, choosing to limit the number of organizational units and levels of hierarchy. Often this is done to optimize search performance ⚡. This approach also 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 how they structured their local DIT and why. A site may find this info helpful when deciding how to structure their own local DIT. Ultimately, the decision will depend on the needs of the local organization and expectations of Directory usage 🫶.
Valdis Kletnieks of the Virginia Polytechnic Institute:
"For Virginia Tech, it turned out to be a reasonably straightforward process. Basically, the University is organized on a College/Department basis. We decided to model that "real" structure in the DIT for two major reasons: "(a) It duplicates the way we do business, so interfacing the X.500 directory with the "real world" is easier. "(b) With 600+ departmental units and 11,000+ people (to be 30,000+ once we add students), a "zero" (everybody at top) or "one" deep (600 departments at top) arrangement just didn't hack it - it was deemed necessary that you be able to do a some 120 or 140 county office entries under the Extension service, it's a BIT unwieldy there). However, with some 20 college-level entries at the top, and the "average" college having 30 departments, and the "average" department being from 10 to 40 people, it works out pretty well."
Jeff Tannehill of Duke University:
"Our DIT is flat. We get the entire database of people at Duke from Tel-Com and just put everyone directly under "O=Duke University". "Actually, there is an exception, when the DSA was first set up and we had not received a database yet, I configured the DIT to include "OU=Computer Science", under which myself and one other System Administrator have entries. Upon getting the database for everyone else I decided not to attempt to separate the people in the database into multiple ou's."
Joe Carlson of Lawrence Livermore National Laboratory:
"We tried both flat (actually all under the same OU) and splitting based on internal department name and ended up with flat. Our primary reason was load and search times, which were 2-3 times faster for flat organization."
Paul Mauvais of Portland State University:
"We originally set up our DIT by simply loading our campus phone book into one level down from the top (e.g. OU=Faculty and Staff, OU=Students, OU=Computing Services). "I'd love to have an easy way to convert our flat faculty and staff area into departments and colleges, but the time to convert the data into the separate OU's is probably more than I have right now."
Mohamed Ellozy of Dana-Farber Cancer Institute:
"Here we have a phone database that includes department, so we got the ou's with no effort. We thus never went the flat space way."
Dan Moline of TRW:
"Well - we're still in the process of defining our DIT. TRW comes under the international companies DBA. Our part under the PSI White Pages Pilot defines the DIT for our space and defense organization here in Redondo Beach (however, I organized the structure to adhere to TRW corporate). We input from our manpower DB for our S&D personnel. We're trying to get corporate's DB for possible input. "However, arranging your DIT by organizations (at least for corps) presents a problem; things are always being reorganized! We were DSO now we're SSO!!! We still have some of our old domain name for DNS tied to organizations that have not existed for years! "So we are currently redesigning our DIT to try to fit NADF 175 (something more geographically). Our reasoning was that organizations may change but buildings and localities do not."
Ruth Lang of SRI:
"There has been no SRI-wide policy or decision to participate in the PSI White Pages Pilot.@c=US@O=SRI Internationalsupports 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 thisO=SRI International, I usedOU=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 🎀
Okay so the Phase I rollout of X.500 should be limited to "white pages"-type info 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::APSThe list above is a minimum set that is recommended for a person's entry 🌸. You may choose to leave some attributes out for reasons of privacy or legality 🙈. Note that the X.500 standard requires that the surname and commonName attributes be present 📌. If someone's phone number and/or address can't be provided, it should be replaced with the site's "Information Phone Number" and postal address so people still have some way to reach them 🫶.
2.5.1. Information Security 🔐
Okay, this part is serious bestie. Putting this type of info in X.500 is basically the same as putting the "Company Phone Book" online on the Internet 📖😭. Different sites may treat this information differently 💜. Some may see it as confidential, while others are totally fine with it being public 🌈. Either way, ESnet sites were advised to talk it over with their legal departments before making their info openly available ⭐.
Heads up: 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 gives you lots of ways to get at the info in the X.500 Directory ✨. Non-interactive access mechanisms (like WHOIS, FINGER and Electronic Mail) use capabilities or services that already live on lots of workstations and hosts 💻. That means these hosts can use the X.500 service right away with no extra software or reconfiguration 🙌. But since these methods are non-interactive, they only let you search for and read info in the Directory. There's no way to modify anything with them 🙈.
2.6.1. Directory Service via WHOIS 🔍
The Pilot Project software lets you set up the X.500 Directory service on a network port that emulates the SRI-NIC WHOIS service 🧚. UNIX-based hosts and VMS hosts running Multinet usually come with WHOIS already set up 💖. So users at their workstations can issue a simple WHOIS command to a known host running a DSA and look up colleagues at their own site or at other ESnet sites 👑. For example, this command:
whois -h wp.lbl.gov wrightwill return info about Russ Wright at Lawrence Berkeley Lab 🌟. It is recommended that every site that sets up this service gives the host running its DSA an alias of the form <wp.site.domain>, so the whole ESnet community stays consistent 🎀.
2.6.2. Directory Service via Electronic Mail 📬
The Pilot Project software also lets you reach the X.500 Directory service through electronic mail 💌. If you send an email to a known host running a DSA with a WHOIS-like command on the subject line, you'll get a reply email with the results of your query 🦋.
2.6.3. Directory Service via FINGER 👀
The X.500 Directory service could also be reached through the FINGER service 🍓. This access method doesn't come with the PSI Pilot Project software, but several sites have already built a FINGER interface to the X.500 Directory 🌸. For ease of use and consistency, one single FINGER interface should be picked, and then individual implementations in the ESnet community should conform to it 🫶.
2.6.4. Directory Service via Specialized Applications 🛠️
There are tons of X.500 Directory User Agents (DUAs) out there 🤩. Some of them come with the PSI Pilot Project software, and other DUAs that third parties built to fit into the pilot software are publicly available too 🌈. These user agents support interactive access, so you can browse, search, list and modify data in the Directory 💅. But most of the time, using these DUAs means the Pilot Project software has to be installed on the host system 😤. Here are a few of these DUAs and what they can do:
- 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 🧑💻.
- 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 💖.
- 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 don't have the computing power or the software needed to run a full OSI protocol stack 😭. Because of that, several "light-weight" protocols were developed where the DAP runs on a capable workstation and exposes a simpler interface to other end-systems ✨. One of these, the Directory Assistance Service (DAS), is built into 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 the PC have been built using the DA-service and the DIXIE protocol 💜. As long as you have the Pilot Project software running on one host, you can offer these User Agents on lots of end-systems without installing the Pilot software on every single one 🙌.
For more info about available Directory User Agents, see RFC-1292, "Catalog of Available X.500 Implementations" 📚.
2.7. Services Provided by ESnet 🌈
Right now, several ESnet backbone sites are running their own DSAs as part of the PSI White Pages Pilot Project 👑. It's expected that directly connected ESnet backbone sites will eventually install and operate their own X.500 DSAs 🌟. In the meantime, ESnet will give complete support to ESnet backbone sites that don't currently have the time, expertise or equipment to set up X.500 services 🫶. The mechanism for doing this is described in Section 2.7.5 below 📖. ESnet will also provide a bunch of services for the entire X.500 community, and those are covered in the following sections too 💅.
2.7.1. X.500 Operations Mailing List 📮
ESnet runs a mailing list for talking about X.500 topics 💬. It's a place to share info, experiences, and expertise about X.500 in the ESnet community 🦋. New sites that join the ESnet X.500 community will be announced on the list 🎉. New DSA administrators can ask more experienced admins for help there 🫶. When a site brings up a new X.500 DSA, the DSA manager should let the ESnet DSA manager know so they can be added to the mailing list quickly 💌.
General discussion: x500-ops@es.net
To subscribe: x500-ops-request@es.net2.7.2. Accessing the X.500 Directory 🔎
ESnet has made the X.500 service openly available to the whole ESnet community through each of the access methods described in Section 2.6 above 🌸. Host WP.ES.NET offers TELNET access, FINGER and WHOIS emulations, querying through electronic mail, and remote access via light-weight protocols 💻. By making these services widely available, ESnet hopes to introduce more users to what X.500 can do 🧚.
To try out some of the X.500 User Agents, just TELNET to WP.ES.NET and log in as user "fred"; no password is required 🔓. You get to pick between the Fred or Pod User Agents. Fred has a command line interface, and Pod has an X-windows based interface 🎀. You can browse the global X.500 DIT, search for people in various organizations, and even edit your own entry if you have one 🤩.
Host WP.ES.NET also gives access to the X.500 Directory through emulations of the FINGER and WHOIS utilities 💖. These interfaces support a user-friendly-naming (UFN) scheme that makes it way easier to search for people in other organizations 👑. The following WHOIS command lines show how to search for people at various ESnet sites using UFN syntax (similar FINGER command lines could also be built) 🦋:
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",lblFor more info about User Friendly Naming, check out 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 different parts of the DIT 🌍. For example, National Laboratories will go directly under the c=US portion of the DIT, while universities and commercial entities will most likely go under localities, like states or cities 🏫.
To make it easier to search 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 are actually aliases that point to the site's "real" organizational entry 🪄. So ESnet backbone sites will be listed in two different places in the DIT, and you can search for them in either location 🫶💜
2.7.4. Multiprotocol Stack Support ✨
okay so OSI apps are literally running over a bunch of different transport/network protocol combos 😭, and that makes it hard for OSI end nodes to talk to each other 💀. to fix that, 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 CLNPwithin the ESnet crew, the stacks of interest are RFC-1006 over TCP/IP, TP4 over CLNP, and TP0 over X.25 🎀. if a backbone site's DSA is not running over all three of these stacks, it may eventually receive referrals to a DSA that it can not connect to directly, so the operation can not proceed 🙈. since the ESnet DSAs will be configured to operate over all of the "stacks of interest," they can serve as relay DSAs between site DSAs that do not have direct connectivity 🦋. the site's DSA manager will need to contact the ESnet DSA manager to arrange for this relaying to occur. backbone sites will be encouraged to eventually provide as many of the three stacks of interest as possible 🌈.
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, which means the site gets to join the PSI Pilot Project and the ESnet X.500 community 🫶. to make this happen, the site must provide the ESnet DSA manager with information about the people to be included in the X.500 Directory. this info 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 lets you 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.
bestie, read that twice 🚨. anything you hand to the ESnet DSA is world readable, so if something is private, keep it out of the file or run your own DSA. no exceptions, no cap.
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 🥲.
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@wpthis 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/aone 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 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 gives the ESnet community several advantages 🌸:
- 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 🛡️.
- All queries to Level-0 DSAs remain within the ESnet high-speed backbone 🚄.
- 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 is usually a local matter. however, all siblings under a given node in the DIT must have unique RDNs 🧁.
see Section 4 for a more complete description of OSI registration issues and procedures 📚.
2.10. Future X.500 Issues to be Considered
2.10.1. ADDMDS Interoperating with PRDMDS
this is a problem which currently does not have an answer 😭. the issue of Administrative Directory Management Domains (ADDMDs) interacting with Private Directory Management Domains (PRDMDs) is just beginning to be investigated by several groups interested in solving this problem 🔍.
2.10.2. X.400 Interaction with X.500
the current level of understanding is that X.400 can benefit from the use of X.500 in two ways 💭:
- Lookup of message recipient information.
- 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 to 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 service within the Internet community 📖. however, the X.500 standard provides for much more than just this service. application processes, devices and security objects are just a few of the objects to be considered for future incorporation in the global X.500 database 🧠.
2.10.5. Introduction of New X.500 Implementations
thought will have to be given to the use of commercial X.500 products in the future, as QUIPU (the implementation recommended in this paper) may not meet all of the needs of the ESnet community 🤔. as commercial products mature and become stable, they will have to be incorporated into the ESnet X.500 service in a way which ensures interoperability and reliability 🔧.
2.10.6. Interaction of X.500 and DECdns
there is every indication that DECdns and X.500 will interoperate in some fashion in the future ✨. since there is an evolving DECdns namespace (i.e. OMNI) and an evolving X.500 DIT (i.e. NADF), some consideration should be given to how these two name trees will interact 🌳. all of this will be driven by the Digital Equipment Corporation's decisions on how to expand and incorporate its DECdns product with X.500 🏢.
3. X.400 - OSI Message Handling Services 📬
3.1. Brief Tutorial ✨
okay so bestie, let's start at the very beginning 🎀 In 1984 CCITT defined a set of protocols for swapping electronic messages, called Message Handling Systems (MHS), and they're described in their X.400 series of recommendations. 💌 ISO took those recommendations into its own standards (ISO 10021), and ISO called its version MOTIS (Message-Oriented Text Interchange Systems). In 1988 CCITT worked on lining up its X.400 recommendations with ISO 10021. Nowadays, when people talk about messaging systems, they just say X.400 🫶 Both systems are built for the same general job: exchanging electronic messages in a store and forward environment. The main thing they're used for today is electronic mail. This section gives you the overview of X.400 as it's used for email, and from here on out, "X.400" means both the X.400 and MOTIS systems 💅
The basic model is a Message Transfer System (MTS) accessed through a User Agent (UA). A UA is the app that talks to the MTS to submit messages on behalf of a user 📬 A user is called an Originator when sending and a Recipient when receiving. The whole process starts when an Originator writes a message with help from their UA. The UA then submits it to the MTS for delivery, and the MTS delivers it to one or more Recipient UAs.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
______ | _______ _______ | ______
| | | MTS | | | | | | |
| UA |<----|---->| MTA |<------>| MTA |<---|--->| UA |
|______| | |_______| |_______| | |______|
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|The MTS is the general store-and-forward message transfer service 🦋 It's made up of a bunch of distributed Message Transfer Agents (MTAs). Operating together, the MTAs relay the messages and deliver them to the intended recipient UAs, which then make the messages available to the recipient (user) 🌸
An X.400 message is an envelope plus content (i.e. message). The envelope carries the info needed to move the message through the MTS 🧚 The content is the piece the originating UA wants delivered to the recipient UA. There are lots of content types that can ride in X.400 envelopes. The standard user message content type is the Interpersonal (IP) message. An IP message has two parts: the heading, which holds the message control information, and the body, which holds 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 all at once 🤯
The Management domain (MD) concept is the ownership, operational and control boundary of an X.400 administration 👑 A collection of at least one MTA and zero or more UAs owned by an organization or public provider makes up a management domain (MD). If the MD is managed by a public provider, it's called an Administration Management Domain (ADMD). An 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, and 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, and it's built from a set of standard attributes:
- Country Name
- Administration Management Domain
- Private Management Domain
- Organization Name
- Organizational Unit Name
- Surname
- Given name
- Initials
- 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. Right now, each MD along the route a message takes determines the next MD's MTA that the message should be transferred to. No attempt is made to establish the full route for a message, either in the originating MD or in any other MD that picks up the store and forward responsibility for the message 🗺️
Messages are relayed by each MD based on the Management domain portion of their O/R Name until they arrive at the recipient MD. At that point, the other attributes in the name are used to route the message further to the recipient UA. Internal routing within an MD is the responsibility of each MD.
3.2. ESnet X.400 Logical Backbone 🌈
Right now, within the ESnet community, message handling services run on a bunch of different mail products, which is classically known as an "n-squared" problem 😭 Let's say 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, it 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 same scenario exists for CEBAF.
To fix that, a logical X.400 backbone must be established throughout the entire ESnet backbone 🦋 Then, each ESnet backbone site will be responsible for only providing connectivity between its 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 they're 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 like this:
/.../O=<site>/PRMD=ESnet/ADMD= /C=US/A few examples of possible X.400 ORnames using that syntax are:
/PN=Smith/OU=Computations/O=LLNL/PRMD=ESnet/ADMD= /C=US/
/PN=Jones/OU=Physics/O=PPPL/PRMD=ESnet/ADMD= /C=US/These sites will operate an MTA at the /O=<organization> level in the name hierarchy 🧚
3.3.2. Operating a Site Private Management Domain 🍓
ESnet backbone sites which operate a PRMD will have an X.400 name syntax like this:
/.../O=<org>/PRMD=<site>/ADMD= /C=US/A few examples of possible X.400 ORnames using that 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 charactersNOTE: 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 ✨
Okay so, in the IP world an SMTP MTA can use the Domain Name Service (DNS) to find connection info for the host closest to the recipient 💅. X.400 is not that chill 😭. MTAs must know the remote MTA's name and password along with connection info, because some X.400 systems have access control requirements 🔐. Someday X.500 is supposed to provide this info, at some future date. Until then, routing in the X.400 community is table driven, which means someone has to coordinate and distribute those tables so updates happen quickly and reliably 🫶.
The current plan for X.400 routing is to chop the X.400 address space into a hierarchy, where each node is the entry point for one X.400 domain 🌳. These nodes are commonly called Well Known Entry Points (WEPs) ✨. Each WEP represents 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 keep hops between Originators and Recipients to a minimum, the X.400 community currently recommends that every PRMD peer with all other PRMDs 🦋. It's giving full mesh energy.
The ESnet backbone will provide connectivity between multiple PRMDs (the ESnet PRMD and any site operated PRMDs), and each one has its own well-known entry point MTAs 🌸. Each of these PRMD-level MTAs must be configured with routing and mapping information about each other so they can do peer-to-peer PRMD routing. These routing tables should be updated immediately once new or changed X.400 connectivity info is discovered 🚨. The tables will be made available to the ESnet community through the ESnet Information Server. Once they're online, a notification message announcing the new routing info goes to every WEP owner through the E-mail mechanism described in Section 3.5.1 📬. It is recommended that WEP administrators should grab 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 this address:
/PN=Funk/OU=CS/O=PPPL/PRMD=ESnet/ADMD= /C=US/to a well-known entry point for PPPL (O=PPPL). PPPL must own and operate their own X.400 MTA, and it must be configured to accept X.400 messages from the ESnet MTA. So the interpretation of the remaining /PN=Funk/OU=CS is left up to the PPPL MTA to route 🧚. Mail sent from PPPL's MTA gets routed to the ESnet MTA (PRMD), which eventually routes it to its destination 💜.
The ESnet MTA will also route to peer MTAs that 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 this 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). So 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) gets routed to the well-known entry point for whichever PRMD is in the destination address.
Also, 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 operated exactly as the standard recommends, PRMDs would only peer with other PRMDs when connectivity is available and traffic demand is high enough, and they'd use ADMD services to reach everyone else 🙄. In reality, a lot of PRMDs won't subscribe to an ADMD service and will only be reachable through PRMD peering 😤.
Most communities, like ESnet, want the fullest PRMD interconnectivity possible so they don't need ADMD services as much 💖. The community PRMD operational requirements come from a policy of achieving large scale peering among PRMD operators within the community 🌈.
The IETF X.400 Operations Working Group is still working on an RFC that specifies the operational requirements that X.400 Management Domains must implement 🛠️. That document is titled "Requirements for X.400 Management Domains (MDs) Operating in the Global Research and Development X.400 Service", and it's listed in Appendix G. ESnet will comply with all the requirements in that document, and it is the recommendation that all ESnet PRMDs follow them too 💅✨.
As an overview, that document specifies that each PRMD will provide at least one WEP and that all PRMDs must be interconnected 🔗. A bunch of PRMDs in the International X.400 service use different communication stack requirements, like this:
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 CONSTo meet the requirement that all PRMDs are interconnected, a PRMD must support one or more of the stacks above. For any stack it doesn't support, the PRMD must negotiate with another PRMD or ADMD to relay messages to a Management Domain that does support that stack 🤝.
The PRMD requirements also suggest that PRMDs support downgrading from X.400 1988 to X.400 1984 🔙. Also, the PRMD must be reachable from the Internet Mail service, which 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 needed 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 or site needs to decide whether it's going to comply with the PRMD requirements above, or act as an organization associated with the ESnet PRMD 🤔. At minimum, an organizational MTA only has to support one of the protocol stacks provided by its associated PRMD. But in all cases, the site needs to provide a WEP and register or list its MTA(s) with ESnet 📝.
3.5. Services Provided by ESnet
ESnet will provide PRMD service to those members of the ESnet community who want 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 goal is to offer the fullest PRMD level X.400 services possible 🚀.
ESnet will deploy two PRMD level X.400 MTAs in geographically disperse locations 🗺️. These MTAs will be able to forward mail for directly connected ESnet backbone sites, as well as to and from the peered PRMDs 🦋.
3.5.1. X.400 Operations Mailing List
ESnet will provide an X.400 operations mailer for announcements and for sharing X.400 operational information in the ESnet community 📣.
General discussion: x400-ops@es.net
To subscribe: x400-ops-request@es.net3.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 info will be available for configuring directly connected ESnet site operated MTAs. It 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 decide the details of the information format, the update frequency, how it's obtained, and how it's disseminated, 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 🔌. The ESnet staff will govern the configuration and operation of mail protocol gateway functions 👩💻.
Backbone site MTAs that service ORnames at the /O=<site> level under the ESnet PRMD must utilize one of the ESnet PRMD supported protocol stacks. This requirement makes sure all users of the ESnet PRMD can communicate with one another via the ESnet PRMD MTA 🫂.
Backbone site MTAs that 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 makes sure all PRMDs in the ESnet community can peer with the ESnet PRMD 🌈✨.
3.5.5. Registering/Listing your PRMD or Organizational MTA with ESnet 📬
Okay bestie, so for X.400 connection and routing to work, you're going to need to register/list your MTA with ESnet 💖 ESnet keeps this info in tables on the ESnet Information Server. ESnet also keeps info on the International X.400 service, and it uses the same format for that info as the International X.400 service does. You can read all about it in an IETF X.400 operations paper called "Routing Coordination for X.400 MHS Services within a Multiprotocol/Multinetwork Environment". It's a working draft (see Appendix G), and it describes a machine independent form for distributing X.400 info 🧚
There are three tables that must be maintained and exchanged by the top level WEPS. Literally three, so don't forget any 👑
- The Community Document
- The WEP Document
- The Domain Document
ESnet will submit these documents to the International X.400 community on behalf of the ESnet Community. If an ESnet PRMD wants to peer with the International PRMDs, they will need to submit these documents to that community too 💅
The Community document lists 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. ESnet will submit this document to the International X.400 service for the ESnet Community. ESnet PRMDs and Organizations do not need to submit this form to ESnet. But if an ESnet PRMD wants 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 lists the WEPs used by an ESnet MHS domain, and it has all the info 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 is a list of WEPs, with the following info for each one:
- The MTA Name
- Password
- Which MTS supported
- Which standard, 84 and/or 88
- Connection information outbound
- Connection information inbound
- Computer system information
- Point of contact
The Domain Document specifies all the X.400 domains managed by a site. It shows the person responsible and which WEP services which Domain. This document repeats the following info for each Domain:
- X.400 Domain
- Point of Contact
- 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. Yikes, the FTS-2000 charge for routing X.400 messages is $.45 (US) plus X.25 packet charges 😭 That could mean a charge of several dollars for large messages, which is a real possibility with the multi-media capacity of X.400. Paying this fee is not within the charter of ESnet, and 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 it allows direct PRMD-PRMD peer routing ✨ Since national uniqueness is required, registration should be done through an appropriate registration authority (such as ANSI).
X.400 organization names must be unique within a PRMD. There's no need for national uniqueness here. Registration of an X.400 organization name should be conducted through the PRMD operator.
Registration of X.400 names below the organization level is usually a local matter. Uniqueness within the context of a superior name should always be maintained 🫶
See Section 4 for a more complete description of OSI registration issues and procedures.
3.8. Future X.400 Issues to be Considered 🔮
3.8.1. X.400 Mail Routing to International DOE Researchers 🌍
Right now there are DOE researchers located in Switzerland, Japan, Germany, China and Brazil. PRMD level connectivity to these international locations does not exist at the moment. ESnet isn't chartered to pay for commercial X.400 services on behalf of the ESnet community, so "buying" this service is not a viable option 🙈
There are efforts underway to provide international X.400 service over the (international) Internet. Once that becomes fully operational, more research will have to be done to see if it provides the X.400 connectivity needed to support the DOE researchers 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 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 to support "downgrading" to 1984 X.400, to make sure X.400 mail delivery to the ESnet community stays reliable 💜
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 set up 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, and that's how the tree forms 🌳
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. Names are meant to be stable, so 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. It also gives 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).
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. Info 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. 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 back 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, though, 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).
People often use the term "registration" to describe both activities, and that's 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 the states delegate that administrative right to it. 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 that are of interest to the ESnet community: ANSI, GSA, U.S. DOE and the states. An overview of the ANSI, GSA, and U.S. DOE procedures is given in later sections.
To maintain national uniqueness, a "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.
- ANSI names are of the form
"name". - GSA names are of the form
GOV+name. - U.S. DOE names are of the form
GOV+USDOE+name. - State names are of the form
CA+name(using California).
State name registration authorities are not in operation at this time. Using U.S. DOE as a nationally unique name registration source is not recommended, due to the awkwardness of a double constructed name 🙅♀️
4.4. How to Apply for ANSI Organization Names 💰
ANSI is the root U.S. source of OSI recognized nationally unique organization names. ANSI registration costs $2500 and results in both an alphanumeric name and an associated numeric name. These names may be used for a variety of purposes in X.400, X.500, and other OSI services ✨
For ANSI OSI organization name registration forms and instructions, 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-4976ANSI 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's 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. Its 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 nationally unique.
For GSA OSI Organization Name registration forms and instructions, 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. 204054.5.1. GSA Designated Agency Representatives
Okay bestie, when you fill out the GSA registration form, a designated agency representative has to sign where it says "Registration Official Name and Signature" ✍️🎀 No signature, no registration. GSA will refuse requests missing this signature 💀
The GSA designated Agency Representative for the Department of Energy is:
Steve Hackman
Electronics Engineer
U.S. Department of Energy
AD-241.3/GTN
Washington, D.C. 20585
Office Phone: (301) 903-6111
Office FAX: (301) 903-4125
E-Mail: hackman@gosip.xosi.doe.gov4.5.2. Forwarding of ANSI Registrations to GSA
Here's a super handy trick 🦋 ANSI registration requests can be forwarded automatically to the GSA. That's basically the same as registering with both ANSI and GSA at once. You end up with two nationally unique OSI name registrations: name from ANSI and GOV+name from GSA.
There's no GOSIP requirement for GSA registration, but lots of people feel the extra GSA registration may be useful 🌸
If your organization is a federal government organization, answer the last three questions on the ANSI registration form like this:
- Do you wish the information supplied in the request to remain confidential? NO.
- Do you wish to have your organization name registered with the U.S. GOSIP Registration Authority (a.k.a. GSA)? YES.
- Is your organization an organization of the Federal Government? YES.
You must indicate on the application form that the GSA designated agency representative (Steve Hackman) approved it. He doesn't sign as "Signature of Requestor," but some note of his approval must be attached, or GSA will reject the forwarded application 🚫 Don't skip this one, bestie!
4.6. How to Apply for U.S. DOE Organization Names
ESnet sites are encouraged to review the DOE GOSIP procedures and guidelines while planning their GOSIP activities 🧚 This document does not conflict with current DOE GOSIP policies, so we're all good ✨
DOE can assign nationally unique names that are prefixed by the string GOV+USDOE+. Using this name source is not recommended. There's no apparent advantage to picking U.S. DOE over GSA as a source of nationally unique names, so 🙅♀️
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 stuff can get messy when it comes to the rights to use a name you want 😭 OSI name registrations are not meant to "legally protect" name usage rights. That's just not what they're for.
Please, please talk to legal experts about the rights to use any name you're registering. This recommendation doesn't offer specific legal guidance, but applying for a trademark may be considered as a way to assert or protect your rights to a name 👑
Per the PTO trademark application instructions, there may be several benefits to getting a trademark:
- The filing date of the application is a constructive date of first use of the mark in commerce (this gives the registrant nationwide priority as of that date).
- The right to sue in Federal court for trademark infringement.
- Constructive notice of claim of ownership.
- 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 get a trademark application and detailed instructions from the U.S. Department of Commerce, Patent and Trademark Office. You can do this by mailing your request to the address below, or by calling the PTO at the phone number below 📮
U.S. Department of Commerce
Patent and Trademark Office
Washington, D.C. 20231
Phone: (703) 557-INFONOTE: The following information is based on ESnet experience in filing for a trademark based on prior use. 🌟
After you receive your application, you'll need to do these steps:
- Complete the written application form. If you have more than one name you're filing, you must complete a separate form for each name 📝
- Provide a black-and-white drawing of the mark. If there's no artwork and only text, the text must be centered on the page in uppercase.
- Provide a check in the amount of $175 (for each application), made payable to the Commissioner of Patents and Trademarks 💸
- 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 one tied to a different service class. That means trademarks are not nationally unique 🦄
Before you submit your form, check whether your trademark is already registered to someone else (for the service class you picked). Your legal department usually does this through the PTO Trademark Search Library 🔍
Since the PTO form is a legal document, you must bring in your legal department, and only someone who is a legally recognized representative of your organization can sign the documents. For example, when 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 going on in the ANSI and CCITT communities about a formal registration of all ADMD and PRMD Names (not just ANSI Organization Names) 👀 The ideas being tossed around include a separate ANSI national registry for these names, and a periodic "license" fee. This is only in the idea discussion phase right 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 Administration Management Domain (ADMD) is a management domain managed by an Administration. These are generally one of the common carriers (e.g. AT&T, MCI, U.S. Sprint, etc.).
ADMINISTRATIVE AUTHORITY - An entity that 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) that is managed by an administration.
AE - See APPLICATION ENTITY.
ALIAS - An entry of the class "alias" that holds information used to give an object an alternative name 🎭
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 that is ultimately responsible for managing communication between application processes (APs).
APPLICATION PROCESS - An application process is an object executing in a real system (computer).
APPLICATION SERVICE ELEMENT - An Application Service Element (ASE) is the building block of an Application Entity (AE). Each AE consists of one or more service elements, as defined by its application context.
ASE - See APPLICATION SERVICE ELEMENT.
ATTRIBUTE - An attribute is the information of a particular type about an object that appears in the entry describing that object in the Directory Information Base (DIB).
ATTRIBUTE TYPE - An attribute type is the part of an attribute that shows what class of information that attribute gives.
ATTRIBUTE VALUE - An attribute value is a specific 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 wants to communicate 💌
CCITT - An international standards-making organization that specializes in international communications standards and was 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 that a Directory System Agent (DSA) can optionally use when it can't perform an operation itself. The DSA chains by invoking the operation of another DSA, then relaying the outcome back 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) wants delivered to the recipient UA. For inter-personal messaging (IPM) UAs, the content is either an IP message or an IPM-status-report.
COOPERATING USER AGENT - A User Agent (UA) that works with another recipient's UA to make communication between the originator and the recipient easier 🫶
DAP - See DIRECTORY ACCESS PROTOCOL.
DELIVERY - The interaction in which the Message Transfer Agent (MTA) hands a recipient User Agent (UA) the content of a message, plus the delivery envelope 📬
DELIVERY ENVELOPE - The envelope that 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. It provides directory services to its users, which let them access that 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) that contains information about an object.
DIRECTORY INFORMATION BASE - The Directory Information Base (DIB) is the complete set of information the Directory gives access to. It includes every piece of information that 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) thought of 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) that a single organization manages 🏰
DIRECTORY SYSTEM AGENT - okay so a Directory System Agent (DSA) is an OSI application process that's 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 who accesses the Directory 💖
DIRECTORY USER AGENT - a Directory User Agent (DUA) is an OSI application process that represents the user when they're accessing the Directory ✨
DISTINGUISHED NAME - the distinguished name of a given object is the sequence of relative distinguished names (RDNs) of an entry that 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 that's currently used on 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's the code and format of information that shows up in the body of an IP-message 🎀 examples of coded information types are Telex, TIFO (Group 4 Facsimile), and voice 📠
ENVELOPE - a place where the information used in the submission, delivery and relaying of a message is kept 💌
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 that government purchasers are required to have, and how those elements should be implemented 🧾 GOSIP is based on OSI standards and OIW implementor's agreements 🤝
HEADING - the heading of an IP-message is the control information that characterizes an IP-message 🏷️
INTERPERSONAL MESSAGING - Interpersonal Messaging (IPM) is communication between persons by exchanging messages 💬
INTERPERSONAL MESSAGING SERVICE - the set of service elements which enable users to exchange interpersonal messages 📨
INTERPERSONAL MESSAGING SYSTEM - an Interpersonal Messaging System (IPMS) is the collection of User Agents (UAs) and Message Transfer Agents (MTAs) which provide the Interpersonal Messaging Service 🎉
IP - a non-OSI network protocol, the Internet Protocol, used extensively across 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 that, 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 made up 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), makes up the Message Transfer System (MTS) 🚚 The MTAs provide message transfer service elements by:
- interacting with originating User Agents (UAs) via the submission dialogue,
- relaying messages to other MTAs based upon recipient designations, and
- 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's 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) that cannot perform an operation itself 📣 The DSA multicasts the operation (i.e. it invokes the operation of several other DSAs (in series or in parallel) and passes an appropriate outcome to the original requestor) 🦋
NAME - a name is a construct that singles out a particular object from all other objects 🎯 A name must be unambiguous (i.e. denote just one object); however, it need not be unique (i.e. be the only name which unambiguously denotes the object) 🫶
NIST - the National Institute of Standards, a government organization which develops, endorses, and promulgates standards for use by the U.S. government 🇺🇸
O/R ADDRESS - see ORIGINATOR/RECIPIENT ADDRESS. 🌸
O/R NAME - see ORIGINATOR/RECIPIENT NAME. 🌸
OBJECT (OF INTEREST) - anything in some "world" (generally the world of telecommunications and information processing, or some part thereof) which is identifiable (i.e. can be named), and which it is of interest to hold information on in the Directory Information Base (DIB) 🔍
OIW - the OSI Implementors Workshop 🛠️ OIW is one of three regional workshops (OIW, EWOS, AOW) which specifies implementation agreements for base OSI standards. OIW's participants are mostly from the Americas, and the OIW is jointly sponsored by the IEEE (Institute of Electrical and Electronic Engineers) and NIST ⭐
OPEN SYSTEMS INTERCONNECTION - a term referring to the capability of interconnecting different systems 🔗
ORIGINATING USER AGENT - the Originating User Agent (UA) is a UA that submits to the Message Transfer System (MTS) a message to be transferred 🚀
ORIGINATOR - a user, a human being or computer process, from whom the Message Handling System (MHS) accepts a message 🙋
ORIGINATOR/RECIPIENT ADDRESS - a descriptive name for a User Agent (UA) that contains certain characteristics which help the Message Transfer System (MTS) locate the UA's point of attachment 🗺️ An Originator/Recipient (O/R) address is a type of O/R name 🍓
ORIGINATOR/RECIPIENT NAME - the Originator/Recipient Name (O/R Name) is the descriptive name for a User Agent (UA) 🏷️
OSI - see OPEN SYSTEMS INTERCONNECTION. 🌸
PRDMD - see PRIVATE DIRECTORY MANAGEMENT DOMAIN. 🌸
PRIMITIVE NAME - a name assigned by a naming authority 🪪 Primitive names are components of descriptive names 🧱
PRIVATE DIRECTORY MANAGEMENT DOMAIN - a Private Directory Management Domain (PRDMD) is a Directory Management Domain which is managed by an organization other than an administration 🔐
PRIVATE MANAGEMENT DOMAIN - a Private Management Domain (PRMD) is a management domain managed by a company or non-commercial organization 🏢
PRMD - see PRIVATE MANAGEMENT DOMAIN. 🌸
RDN - see RELATIVE DISTINGUISHED NAME. 🌸
RECIPIENT - a user, a human being or computer process, who receives a message from the Message Handling System (MHS) 📥
RECIPIENT USER AGENT - a User Agent (UA) to which a message is delivered or that is specified for delivery 🎯
REFERRAL - a referral is an outcome which can be returned by a Directory System Agent (DSA) that cannot perform an operation itself 🙌 It identifies one or more other DSAs more able to perform the operation 🌟
RELATIVE DISTINGUISHED NAME - a Relative Distinguished Name (RDN) is a set of attribute value assertions, each of which is true, concerning the distinguished values of a particular entry 🧠
RELAYING - the interaction by which one Message Transfer Agent (MTA) transfers to another MTA the content of a message plus the relaying envelope 🔁
RELAYING ENVELOPE - the envelope which contains the information related to the operation of the Message Transfer System (MTS) plus the service elements requested by the originating User Agent (UA) 📮
RFC - Request for Comments 💅 The RFC's are documents used to propose or specify Internet community standards 📜
ROOT - the vertex that is not the final vertex of any arc is referred to as the root vertex (or informally as the root) of the tree 🌳
SCHEMA - the Directory Schema is the set of rules and constraints concerning the Directory Information Tree (DIT) structure, object class definitions, attribute types, and syntaxes which characterize the Directory Information Base (DIB) 📐
SDE - see SUBMISSION AND DELIVERY ENTITY. 🌸
SMTP - Simple Mail Transfer Protocol 📧 An e-mail protocol frequently used by the Internet community 💌
SUBMISSION - the interaction by which an originating User Agent (UA) transfers to a Message Transfer Agent (MTA) the contents of a message plus the submission envelope 📤
SUBMISSION AND DELIVERY ENTITY - the Submission and Delivery Entity (SDE) is an entity located in the Message Transfer Layer (MTL), co-resident with a User Agent (UA) and not with a Message Transfer Agent (MTA), and responsible for controlling the submission and delivery interactions with a Message Transfer Agent Entity (MTAE) 🎀
SUBMISSION AND DELIVERY PROTOCOL - the Submission and Delivery Protocol (P3) is the protocol which governs communication between a Submission and Delivery Entity (SDE) and a Message Transfer Agent Entity (MTAE) 🤍
SUBMISSION ENVELOPE - the envelope which contains the information the Message Transfer System (MTS) requires to provide the requested service elements 📫
TCP - a non-OSI transport protocol, the Transmission Control Protocol, used extensively across 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 🌊
Glossary, continued 🎀
TREE - okay so a tree is basically a set of points (vertices) plus a set of directed lines (arcs) 🌳 each arc leads from a vertex V to a vertex V'. V and V' are called the initial and final vertices of an arc a from V to V'. In a tree, several different arcs can share the same initial vertex, but they can't share the same final vertex 🦋
UA - See USER AGENT. 💖
UAE - See USER AGENT ENTITY. 💖
UAL - See USER AGENT LAYER. 💖
USER - a person, or a computer application or process, that makes use of a Message Handling System (MHS) 🧚
USER AGENT - typically, the User Agent (UA) is a set of computer processes (think an editor, a file system, or a word processor) that create, inspect, and manage the storage of messages 💅 there's typically one user per User Agent (UA). while the originator is preparing a message, they talk to their UA through an input/output (I/O) device (like a keyboard, display, printer, facsimile machine, and/or telephone). those same devices also let the UA pass along messages it received from the Message Transfer System (MTS) to the user 📨 and to send and receive messages, the UA works with the MTS through the submission and delivery protocol. the way the UA is the middle person here is lowkey iconic 👑
USER AGENT ENTITY - a User Agent Entity (UAE) is an entity in the User Agent Layer (UAL) of the Application Layer. it controls the protocol that goes with the cooperating UAL services 🎀 it swaps control information with the Message Transfer Agent Entity (MTAE) or the Submission and Delivery Entity (SDE), which sit in the layer below. that control information is whatever the Message Transfer layer (MTL) needs to build the right envelope, so it can deliver the message transfer service elements that were asked for ✨
USER AGENT LAYER - the User Agent Layer (UAL) is the layer that holds the User Agent Entities (UAEs) 🌸
X.25 - a packet switched network standard that public providers use a lot. it's optional in GOSIP 🍓
Appendix A: Current Activities in X.500 🌈
NOTE: the following are edited excerpts from the IETF Directory Services Monthly reports, plus a few IETF scope documents 💜 effort has been taken to make sure this info is current as of late 1991. at the end of each section there are lists of anonymous FTP and/or an e-mail address, in case you want more info 🫶
IETF DISI (Directory Information Services Infrastructure Working Group) 🧚
the Directory Information Services (pilot) Infrastructure Working Group is chartered to help deploy Directory Services on the Internet, based on implementations of the X.500 standards 💖 it's going to do that by producing informational RFCs that work as a Directory Services "Administrator's Guide" 📚 these RFCs cover the current usage and scope of the X.500 standard and Directory Services in North America and around the world, and they include info on procuring, installing, and operating different X.500 implementations ✨ since the various X.500 implementations work equally well over TCP/IP and CLNP, the DISI working group shall not mandate specific implementations or transport protocols 🙈
DISI is an offshoot of the OSI Directory Services group, so it's a joint effort of the OSI Integration Area and the User Services Area of the IETF 🤝 the current OSIDS working group was chartered to smooth out technical differences in information storage schema and to fix trouble with the interoperability and coherence of various X.500 implementations 🔧 the DISI group is only concerned with expanding the Directory Services infrastructure 🎯 since DISI is going to provide info to help build infrastructure with an eye toward truly operational status, it 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 focused on user services, integration, maintenance and operations of Directory Services. that one is the Operations and Infrastructure of Directory Services (OIDS) Group 🌟
one DISI document you might be into 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 : 103this 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.eduIETF OSI-DS (OSI Directory Service Working Group) 🌷
the OSI-DS group works on issues about building an OSI Directory Service using X.500 and deploying it on the Internet 💜 this group isn't directly concerned with piloting, but the focus is practical, so technical work needed as a prerequisite for deploying 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. that infrastructure should be based on the OSI Directory (X.500), and it's meant to be usable by many applications 🌈 this WG isn't directly concerned with running services, but close liaison is expected with the groups that do operate pilots and services 🫶
liaisons have been set up with RARE WG3, NIST, CCITT/ISO IEC, and the North American Directory Forum 🤝
X.500 (1984) / ISO 9594 doesn't have sufficient functionality for full deployment on the Internet, ngl 😭 this group identifies the areas where extensions are required 🔍
it's a basic aim of the group to stay aligned with appropriate base standards and functional standards. any activity should be undertaken in the light of ongoing standardization activity 📏 areas that should be examined include:
- Replication
- Knowledge Representation
- Schema Management
- Access Control
- Authentication
- Distributed operations for partially connected DSAs
- 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 build a basis for operational X.500 deployment in the NREN/Internet 💖 the work is being done at Merit, NYSERnet/PSI, SRI, and ISI. ISI is the main contractor and handles the project oversight 👑
FOX has two primary thrusts:
- X.500 Infrastructure: it's important that multiple interoperable platforms are available for deployment 🧩 FOX plans to examine and test the interoperability of the QUIPU and NIST-X.500 (Custos) implementations, and DNANS-X.500 if possible. FOX will also 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 🪟
- X.500 Applications: the long-range goal is to make X.500 usable for real Internet applications 🌐 FOX will first focus on making network infrastructure information available through X.500. that 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. giving a well-known, widely used service an X.500 version should encourage Internet users to use X.500 📈 this effort will also give 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's critical for Internet X.500 efforts to line up with directory service efforts that are ongoing in other communities. FOX participants are involved in those efforts, or at least tracking them, and info about FOX activities will be publicly available 🌸
NADF (North American Directory Forum) 🗽
the North American Directory Forum (NADF) is a collection of organizations that 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 using existing civil infrastructure for naming objects under c=US. the advantage is that it uses existing registration authorities and doesn't set up any new ones (the document just maps names assigned by existing authorities into different portions of the c=US DIT) 🧠 the document is meant to be the basis for X.500 names in the U.S. for the long term, so it's important that interested parties get a copy, review it, and send back comments 📬
a second output, still in development, is NADF-128, a preliminary draft on "Mapping the DIT onto Multiple ADDMDs". this one describes how the c=US portion of the DIT is mapped onto DSAs, and what service-providers must minimally share to get a working public directory 🗺️ the next revision of this document will likely be ASCII-ized and published as an informational RFC ✨
NIST (National Institute of Standards and Technology) 🏛️
NIST is involved in several X.500 activities: standards, pilot deployment, and development of an X.500 implementation called Custos 🛠️ the goal 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, the emphasis is on access control and replication. the other activities are described in more detail below 💅
- NIST/GSA X.500 Pilot Deployment: NIST and GSA are collaborating on a U.S. Government X.500 pilot deployment 🤝 so far, two meetings have been held. at the second one, held on April 25th at NIST, they made big progress 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 start collecting data to load into the directory. at first, NIST will offer to host agency data on Custos DSAs running at NIST, and eventually agencies are expected to obtain and operate DSAs themselves 🏢
- 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 a simple DBMS is provided as part of Custos to support the DSA. info can optionally be 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, and it's all about getting implementation agreements for emerging international OSI standards done on time ✨. It takes the specs for emerging protocol standards as input and spits out agreements on the implementation and testing details for those protocols. The goal is to speed up OSI protocol development and make sure independently manufactured data communications equipment can actually talk to each other 🫶.
The Workshop runs its work through Special Interest Groups (SIGs) that write the technical documentation 🎀. SIGs are encouraged to coordinate with standards organizations and user groups, and to chase widespread technical consensus on implementation agreements through international discussions and liaison activities 💅.
The Directory SIG 📚 produces agreements on implementing Directory protocols based on ISO 9594 and CCITT X.500 Recommendations. For 1991 it has three major areas on its plate: 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. Its whole mission is promoting OSI to academic, industrial and governmental research and development organizations in Europe 🍓. The countries involved are those of the EC and 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:
- 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 🧚;
- X-Tel Services Ltd, a software company based in Nottingham which currently provides service support to the UK Academic X.500 pilot; and
- PTT Telematic Systems from the Netherlands, which in turn has subcontracted the Swiss and Finnish PTTs, and whose involvement is to create a forum for discussion on X.500 among the European carrier administrations.
The project also aims to have representation from all the participating countries, which in the majority of cases are the existing X.500 national pilots ⭐.
Of the 18 countries involved, at least 12 are registered in the White Pages Pilot Project. Most countries are using the QUIPU implementation developed at UCL. However, a French group has developed PIZARRO, which will form the basis of the emerging French pilot. In Italy, a Torino-based company, Systems Wizards, is 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: uu.psi.com (most X.500 pilot project software is 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 is the group that 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
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 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: mercury.udev.cdc.com (e-mail archive is here)
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:
- Supporting the operational use of X.400.
- Working with others to define organizational procedures necessary to operate X.400 on a large scale in the Internet.
To support the use of X.400, we are operating a PRMD, assisting sites in running PP or the Wisconsin Argo X.400 software packages, and running an X.400 Message Transfer Agent (MTA) which is connected to U.S. and international MTAs using RFC1006/TCP/IP 💜. Internet sites are invited to join our PRMD or establish X.400 connections with us. The organizational work is being done jointly by IETF working groups and RARE Working Group 1.
Mailing list address:
- General Discussion:
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 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:
- 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 🙃.
- 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 🐧.
- 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:
- Remote operations stub-generator (front-end for remote operations)
- Structure-generator (ASN.1 to C)
- 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)
- ISODE 7.0 consists of final "IS" level implementations with the exception of VT, which is a DIS implementation. The ISODE also contains implementations of the 1984 X.400 versions of ROS and RTS 🧠.
- 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 🐛✨. - bestie, the discussion group ISODE@NISC.SRI.COM is an open forum on ISODE and it's giving community 🫶 Contact ISODE-Request@NISC.SRI.COM to get added to the list.
- the primary docs for this release are a five volume User's Manual (approx. 1000 pages) plus a set of UNIX manual pages 📚 The User's Manual sources are in LaTeX format. There are also a bunch of notes, papers, and presentations in the doc set, in either LaTeX or SLiTeX format. If you don't have LaTeX, you should probably grab a hardcopy from one of the distribution sites below 🖨️
ISODE/QUIPU Distribution Sites 🦋
The FTP or FTAM distributions of ISODE-7.0 come as 3 files 📦 The source and main ISODE-7.0 distribution is in ISODE-7.tar.Z, which is roughly 4.7MB.
LaTeX source for the entire doc set is in ISODE-7-doc.tar.Z (3.5MB). A list of documents is in the doc/ directory of the source tree.
A Postscript version of the five volume manual is in ISODE-7-ps.tar.Z (4.3MB) 💖
If you can FTP to the Internet, use anonymous FTP to uu.psi.com [136.161.128.3] to grab the files in BINARY mode from the ISODE/ directory.
Additional PSI White Pages Pilot Software 🌸
The usconfig program configures a DSA that understands some of the NADF naming rules. This software is mainly meant 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.ZWhether or not you use usconfig, please retrieve and install the add-on and follow the instructions in it. You might want to grab pilot-ps.tar.Z again too, since it has an updated Administrator Guide 📖
Note that wpp-addon.tar.Z needs to be installed on top of the ISODE 7.0 distribution. It doesn't include any of ISODE 7.0, so you need to get and generate that too 🧚
PP 6.0 🎀
PP is a Message Transfer Agent built for high volume message switching, protocol conversion, and format conversion 💌 It's aimed at operational environments, but it's also useful for investigating message-related applications. Good management features are a major part of the whole system ✨
PP supports the 1984 and 1988 versions of the CCITT X.400 / ISO 10021 services and protocols. Lots of existing RFC-822 based protocols are supported, along with RFC-1148bis conversion to X.400. PP is an appropriate replacement for MMDF or Sendmail, ngl 💅 This is the second public release of PP, and it includes big changes based on feedback from using PP at many sites.
- PP is not proprietary and can be used for any purpose. The only restriction is that suing the authors for any damage the code may cause is not allowed ⚖️
- PP runs on a range of UNIX and UNIX-like operating systems, including SUNOS, Ultrix, and BSD. A full list of platforms PP is known to run on is included in the distribution 🖥️
- Current modules include:
- X.400 (1984) P1 protocol.
- X.400 (1988) P1 protocol.
- Simple mail transfer protocol (SMTP), conformant to host requirements.
- JNT mail (grey book) Protocol.
- UUCP mail transfer.
- DECNET Mail-11 transfer
- Distribution list expansion and maintenance, using either a file based mechanism or an X.500 directory.
- RFC 822-based local delivery.
- Delivery time processing of messages.
- Conversion between X.400 and RFC-822 according to the latest revision of RFC-1148, known as RFC-1148bis.
- Conversion support for reformatting body parts and headers.
- X-Window and line-based management console.
- Message Authorization checking.
- Reformatting support for "mail hub" operation.
- X.500-based distribution list facility using the QUIPU directory.
- FAX interworking
- 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 🦋
- 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 🤞
- 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.
- PP 6.0 requires ISODE 7.0.
- X-Windows release X11R4 (or greater) is needed by some of the management tools. PP can be operated without these tools.
- 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;- 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 💜
- 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, 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 it's approximately 3Mb in size 🎁
If you can FTP to the Internet from Europe, 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 also the tar image after being run through the compress program, and it's approximately 3Mb in size 🇪🇺
ISODE/QUIPU and PP Platforms as of December 1991 💻
okay bestie, this is the platform lineup 💅 so many machines, so many OS versions, and each row tells you which ISODE and PP versions have been reported on it, plus which protocol stacks showed up 🦋 the Notes column is where the drama is 🙈
Machine OS ISODE PP Stacks Notes
====================================================================
CCUR 6000 RTU 5.0 7.0 Yes! TCP 1
--------------------------------------------------------------------
CCUR 6000 RTU 6.0 7.0 Yes! TCP 2
X25
CLNS
--------------------------------------------------------------------
CDC 4000 Series EP/IX 1.3.2 6.6+ TCP 3
EP/IX 1.4.1 CLNS
X25
--------------------------------------------------------------------
COMPAQ 386/25 SCO Unix 5.2 6.0 TCP
--------------------------------------------------------------------
COMPAQ 386 BSD 7.0 TCP 4
X25
--------------------------------------------------------------------
Convex C120 ConvexOS 8.1 7.0 TCP 5
--------------------------------------------------------------------
DEC Vax 2nd Berkeley Network rel 7.0 TCP
X25
--------------------------------------------------------------------
DEC DECnet-ULTRIX V5.0 7.0 TCP 6
CLNS
--------------------------------------------------------------------
DEC Ultrix 3.1D 7.0 5.2 TCP 7
Ultrix 4.0 X25
Ultrix 4.1
--------------------------------------------------------------------
DEC Ultrix 4.2 7.0 TCP
X25
CLNS
--------------------------------------------------------------------
DEC VMS v5.x 7.0 TCP
X25
--------------------------------------------------------------------
DG Avion DGUX 4.30 7.0 TCP 8
--------------------------------------------------------------------
Encore Multimax 3xx UMAX V 2.2h 6.0 TCP 9
Encore Multimax 5xx
--------------------------------------------------------------------
Encore NP1 UTX/32 3.1a 7.0 TCP 10
X25
--------------------------------------------------------------------
Encore PN6000 UTX/32 2.1b 6.0 TCP 9
Encore PN9000 X25
--------------------------------------------------------------------
HP/9000/3xx HP/UX 6.0 7.0 TCP 11
HP-UX 7.05 B
--------------------------------------------------------------------
HP/9000/8xx HP-UX 7.00 7.0 TCP 11
X25
--------------------------------------------------------------------
IBM 3090 AIX/370 1.2.1 7.0 TCP 12
--------------------------------------------------------------------
IBM PS/2 AIX 1.2.1 6.7 TCP 13
--------------------------------------------------------------------
IBM RS/6000 AIX 3.1 6.8 TCP
AIX 3.0
--------------------------------------------------------------------
ICL DRS/6000 7.0 5.2 TCP 14
--------------------------------------------------------------------
Macintosh A/UX 2.0.1 7.0 TCP
--------------------------------------------------------------------
Macintosh MacOS V6.x 6.0 TCP 15
--------------------------------------------------------------------
Mips 4-52 ATT-V3-0 7.0 5.2 TCP 16
--------------------------------------------------------------------
NeXT 7.0 5.2 TCP 17
--------------------------------------------------------------------
ORION/Clipper 6.8 TCP
--------------------------------------------------------------------
Olivetti LSX-3020 X/OS 2.1 6.7b 5.0 TCP 1
X25
--------------------------------------------------------------------
Pyramid 9800 OSx 5.1 (4.3BSD/SVR3.2) 7.0 5.2 TCP 18
Pyramid MIS
--------------------------------------------------------------------
SEQUENT DYNIX V3.0.18 7.0 TCP 8
--------------------------------------------------------------------
Sony News-1750 NEWS-OS 3.3 6.8 TCP
NEWS-OS 4.0c
--------------------------------------------------------------------
Sun4 SunOS 4.1 7.0 5.2 TCP
Sun3 SunOS 4.1.1 X25
SunOS 4.0.3c CONS
CLNS
--------------------------------------------------------------------okay the Notes list is next and it's a whole vibe 🌸 these explain the quirks for each machine, so read them before you go building anything 🫶
- NOT SNMP or VT
- Little tested
- Official upper layer
- Prototype only!
- Planned port
- Being worked on!
- 3.1D binaries compiled under 4.2
- Only QUIPU confirmed
- Not QUIPU
- Need "-Dregister=" in CONFIG.make
- Need bug-fix no. 5 from bug-ISODE@xtel.co.uk. not SNMP,VT or FTAM-FTP gateway
- No VT, QUIPU not tested
- Models 80 and 95
- NOT SNMP or VT,PP and X.25 requires patches available from X-Tel
- Using MacTCP
- Only QUIPU tested, built using BSD43 config
- Need bug-fix no. 6 from bug-ISODE@xtel.co.uk
- Built using BSD config, no VT or SNMP
ngl the last bit is the real tea ☕ these tables are NOT beta-release territory, so anything newer than the public ISODE-7.0 or PP-5.2 releases isn't covered here 🙈 the whole thing was pieced together from reports sent to bug-ISODE and pp-support, and there's no guarantee the info is correct, so double-check before you trust it fr fr 💀✨
Appendix D: Sample X.500 Input File and Restricted Character List 📇✨
Okay bestie, here's a sample datafile showing how to format info about the people at your site so it can get loaded into the ESnet DSA 💖. There's a detailed breakdown right after it. They really tried to keep the format flexible, given how automated this whole process is, and they'd love feedback on it 🫶. They'll also try to accommodate your specific needs, as long as it's 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>The comment lines at the top of the file carry all the formatting info 🎀.
After those comment lines, every data line holds info about one person 🌸. Fields in a data line are split up by a delimiter character. You pick that delimiter in the comment section, so just make sure you choose one that doesn't show up as a legit 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 go in each field of a data line 📝.
Every data line needs the same number of fields, in the same order (aka the same order of attribute types) 💜. Two delimiters in a row mean a null value, and eof counts as a field delimiter too 🦋.
The characters =, &, $, and # are NEVER allowed in any attribute value 🚫💀.
Here's the breakdown of the important lines in 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: These identify the area code and prefix that apply to all 4-digit extensions in the datafile. If your actual data values already contain an area code and/or prefix, then there's no need to indicate default values, periodt 💅.
- Line 6: Field # 3 is identified as containing the rfc822Mailbox attribute.
- Line 7: Field # 4 is identified as containing the facsimileTelephoneNumber attribute.
- Line 8: This identifies the default value for facsimileTelephoneNumber. If field 4 is missing in a data line, the default value gets applied 🍓.
- Lines 9-12: These identify the value of the postalAddress attribute, which applies to all entries 🧚.
Now the data lines, expanded out. Line 13 looks like this:
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 94552Line 14 looks like this:
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 94552Line 15 looks like this (no email this time, so it's left blank, sad but valid 🥺):
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 94552Line 16 looks like this:
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 94552Line 17 looks like this:
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 94552Line 18 looks like this:
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 94552Appendix E: ESnet Backbone Sites 🛰️🌈
Here's the ESnet backbone crew, sorted by category, bestie. Every one of these sites is part of the squad 💖.
Government Agencies
- U.S. Department of Energy, Office of Energy Research (DOE) — Germantown, Maryland, USA
- U.S. Department of Energy, San Francisco Office (SAN) — Oakland, California, USA
National Laboratories
- NASA Ames Research Center (AMES, FIX-WEST) — Mountain View, California, USA
- Argonne National Laboratory (ANL) — Argonne, Illinois, USA
- Brookhaven National Laboratory (BNL) — Upton, New York, USA
- Continuous Electron Beam Accelerator Facility (CEBAF) — Newport News, Virginia, USA
- Fermi National Accelerator Laboratory (FNAL) — Batavia, Illinois, USA
- Lawrence Berkeley Laboratory (LBL) — Berkeley, California, USA
- Lawrence Livermore National Laboratory (LLNL) — Livermore, California, USA
- Los Alamos National Laboratory (LANL) — Los Alamos, New Mexico, USA
- Oak Ridge National Laboratory (ORNL) — Oak Ridge, Tennessee, USA
- Pacific Northwest Laboratory (PNL) — Richland, Washington, USA
- Princeton Plasma Physics Laboratory (PPPL) — Princeton, New Jersey, USA
- Sandia National Laboratory, Albuquerque (SNLA) — Albuquerque, New Mexico, USA
- Stanford Linear Accelerator Center (SLAC) — Menlo Park, California, USA
- Superconducting Super Collider (SSC) — Dallas, Texas, USA
Universities
- California Institute of Technology (CIT) — Pasadena, California, USA
- Florida State University (FSU) — Tallahassee, Florida, USA
- Iowa State University (ISU) — Ames, Iowa, USA
- Massachusetts Institute of Technology (MIT) — Cambridge, Massachusetts, USA
- New York University (NYU) — Upton, New York, USA
- Oak Ridge Associated Universities (ORAU) — Oak Ridge, Tennessee, USA
- University of California, Los Angeles (UCLA) — Westwood, California, USA
- University of Maryland (UMD, FIX-EAST) — College Park, Maryland, USA
- University of Texas, Austin (UTA) — Austin, Texas, USA
Commercial Entities
- General Atomics (GA) — San Diego, California, USA
- Office of Science and Technology Information (OSTI) — Oak Ridge, Tennessee, USA
- Science Applications, Incorporated (SAIC) — McLean, Virginia, USA
Appendix F: Local Site Contacts for DOE Naming Authorities ✨
Okay bestie, this is the full cast list 💅 Every Department of Energy GOSIP Site Authority for OSI registration and addressing is in here, pulled from the DOE GOSIP On-Line Information System (DOE-GOIS), dated November 18, 1991 🎀 Think of it as the who's-who of who to text when your addressing goes sideways 📱💀
Marian F. Sotel
Director, Information management Division
U.S. Department of Energy
DOE Field Office, Albuquerque
Dennis Jensen
Ames Laboratory
258H Development
Ames, IA 50011-3020
(515) 294-7909
Linda Winkler
Argonne National Laboratory
Argonne, IL 60439
(708) 972-7236
R. E. Kremer
Manager, Resource Automation
U.S. Department of Energy
Bettis Atomic Power laboratory
Gary Ragsdale
Manager, Information Services
U.S. Department of Energy
Bonneville Power Administration
905 NE 11th Avenue
Portland, OR 97232
Wayne Larson
Head of Data Communications Unit
U.S. Department of Energy
Bonneville Power Administration
905 NE 11th Avenue
Portland, OR 97232
George Rabinowitz
Head Distributed Computing Section
Brookhaven National Laboratory
Upton, New York 11973
(516) 282-7637
Donna A. Dyxin
Communications Specialist
U.S. Department of Energy
DOE Field Office, Chicago
9800 South Cass Avenue
Argonne, IL 60439
Elaine R. Liebrecht
System Manager and Planning Supervisor
EG&G Mound Applied Technologies
P.O. Box 3000
Miamisburg, OH 45343-3000
(FTS) 774-3733 or (513) 865-3733
Jeffrey J. Johnson
Communications Supervisor
EG&G Mound Applied Technologies
P.O. Box 3000
Miamisburg, OH 45343-3000
(FTS) 774-4230 or (513) 865-4230
Paul P. Herr
U.S. Department of Energy
Energy Information Agency
(202) 586-7318
William H. Foster
U.S. Department of Energy
Energy Information Agency
(202) 586-6310
Mark O. Kaletka
Data Communications Group Leader, Computing Div.
Fermi National Accelerator Lab
P.O. Box 500
Batavia, IL 60510
(708) 840-2965
David A. Mackler
Grand Junction Project Office
(FTS) 326-6412
Wayne L. Selfors
Grand Junction Project Office
(FTS) 326-6525
Gerald F. Chappell
Director, ITSO
U.S. Department of Energy
Headquarters
Washington D.C., 20545
(FTS) 233-3685 or (301) 903-3685
Joe Diel
Supervisor, Biomathematics Group
ITRI
David H. Robinson
Section Supervisor, Information Systems
Allied-Signal Aerospace Company
Kansas City Division
P.O. Box 419159
Kansas City, MO 64141-6159
(FTS) 997-3690 or (816) 997-3690
Robert M. Jensen
Supervisory Engineer, Information Systems
Allied-Signal Aerospace Company
Kansas City Division
P.O. Box 419159
Kansas City, MO 64141-6159
(FTS) 997-5538 or (816) 997-5538
Russell Wright
Lawrence Berkeley Laboratories
1 Cyclotron Road
Berkeley, CA 94720
(510) 486-6965
William A. Lokke
Associate Director for Computation
Lawrence Livermore National Lab
(FTS) 532-9870 or (669) 422-9870
Philip Wood/Glenn Michel
Los Alamos National Laboratory
Los Alamos, NM 87545
(FTS) 843-1845 or (FTS) 843-2598
Robert Bruen
MIT Laboratory for Nuclear Science
Computer Facilities Manager
Massachusetts Institute of Tech.
Cambridge, MA
Mark Cerullo
Morgantown Energy Technology Center
(FTS) 923-4345
Hank Latham
NVRSN
(FTS) 575-7646
Bill Morrison
Network Specialist
Bechtel Petroleum Operations, Inc
Naval Petroleum Reserves California
P.O. Box 127
Tupman, CA 93276
(FTS) 797-6933 or (805) 763-6933
Mary Ann Jones
DOE Field Office, Nevada
Bill Freberg
Computer Sciences Corporation
DOE Field Office, Nevada
Roger Hardwick
Project Director
Roy F. Weston
OCRWM
3885 S. Decatur Blvd.
Las Vegas, NV 89103
(702) 873-6200
John Gandi
U.S. Department of Energy
OCRWM
101 Convention Ctr
Phase II Complex, Suite 202
Las Vegas, NV 89109
(702) 794-7954
Benny Goodman
U.S. Department of Energy
OSTI
Raymond F. Cook
U.S. Department of Energy
OSTI
D. M. Turnpin
Martin Marietta Energy Systems, Inc
Oak Ridge
P.O. Box 2009
Oak Ridge, TN 37831-8227
(FTS) 626-8848 or (615) 576-8848
T. E. Birchfield
Supervisor, Electronic Informations Delivery Sect.
Martin Marietta Energy Systems, Inc
Oak Ridge
P.O. Box 2008
Oak Ridge, TN 37831-6283
(FTS) 624-4635 or (615) 574-4635
Bobby Brumley
TRESP Associates
DOE Field Office, Oak Ridge
Mike Letterman
TRESP Associates
DOE Field Office, Oak Ridge
S. Dean Carpenter
Department Head, Communications
Mason and Hanger
Pantex Plant
Wayne C. Phillips
Section Head, Internal Communications
Mason and Hanger
Pantex Plant
A. J. Lelekacs
Sr. Networking Engineer
General Electric
Pinellas Plant
P.O. Box 2908
Neutron Devices Department
Largo, FL 34649-2908
Paul A. Funk
Site Access Coordinator
Princeton Plasma Physics Laboratory
P.O. Box 451
Princeton, NJ 08543
(609) 243-3403
John Murphy
Branch Chief, Information and Communication Mgmt
U.S. Department of Energy
DOE Field Office, Richland
P.O. Box 550
Richland, WA 99352
(FTS) 444-7543 or (509) 376-7543
Mike Schmidt
Telecom & Network Services IRM
Westinghouse Hanford Company
DOE Field Office, Richland
P.O. Box 1970
Richland, WA 99352
(FTS) 444-7739 or (509) 376-7739
Dwayne Ramsey
Information Resources Management Division
U.S. Department of Energy
DOE Field Office, San Francisco
(FTS) 536-4302
W. F. Mason
Central Computing Systems Manager
Sandia National Laboratories - AL
P.O. Box 5800
Albuquerque, NM 87185
(FTS) 845-8059 or (505) 845-8059
Harry R. Holden
U.S. Department of Energy
DOE Field Office, Savannah River
P.O. Box A
Aiken, SC 29802
(FTS) 239-1118 or (803) 725-1118
Reggie Peagler
Network Security Officer
Savannah River Site
Building 773-51A
Aiken, SC 29808
(FTS) 239-3418 or (803) 557-3418
Wade A. Gaines
Acting ADP Manager
U.S. Department of Energy
Southeastern Power Administration
Samuel Elbert Building
Elberton, GA 30635
Paul Richard
Southwestern Power Administration
(FTS) 745-7482
Dr. R. Les Cottrell
Assistant Director, SLAC Computer Services
Stanford Linear Accelerator Center
P.O. Box 4349
Stanford, CA 94309
John Lucero
Systems Analyst, Management Systems
Westinghouse Electric Corporation
Waste Isolation Pilot Plant
P.O. Box 2078
Carlsbad, NM 88221
(FTS) 571-8459 or (505) 887-8459
Lawrence Bluhm
Sr. Systems Analyst, Management Systems
Westinghouse Electric Corporation
Waste Isolation Pilot Plant
P.O. Box 2078
Carlsbad, NM 88221
(FTS) 571-8459 or (505) 887-8459
Ben Sandoval
Western Area Power Administration
(FTS) 327-7470
John Sewell
Western Area Power Administration
(FTS) 327-7407"Directory Requirements for COSINE and Internet Pilots (OSI-DS 18)", S.E. Hardcastle-Kille, 07/09/1991.
okay so this one lays out the operational requirements for DUAs and DSAs in the Internet and COSINE communities 🎀 it sums up the conformance requirements, and for most things the technical detail lives in other docs it points to. it's all about core directory infrastructure, and every application that uses the directory might bring its own extra requirements 💅
"DSA Naming", S.E. Hardcastle-Kille, 01/24/1992.
this doc calls out a few problems with DSA Naming as it's currently deployed in pilot exercises, and suggests a new approach 🦋 the approach is suggested for use in the Internet Directory Pilot, which overcomes a bunch of existing problems and is an important piece for the next stage of scaling up ✨
"Handling QOS (Quality of service) in the Directory", S.E. Kille, 08/29/1991.
this one 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.
so WHOIS and Network Infrastructure info is getting folded into X.500 🧚 and the authors figured it'd be super helpful to write down the current DIT structure for it, plus some ideas on how this subtree of the DIT could grow and get organized later. section one covers the structure as it stands, and section two covers the possible expansion 🫶
"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 moves into an operational structure that's increasingly used as a primary resource for Directory Information, it was obvious that having the Internet Site Contacts and some limited network information in the Directory would be immediately useful 🍓 it would also give the preliminary framework for some distributed NIC functions. this paper describes the interim schema used to hold this information 💜
"Naming Guidelines for Directory Pilots", P. Barker, S.E. Kille, 01/30/1992.
deploying a Directory gets way easier if you follow certain guidelines 🌸 this doc defines a number of naming guidelines, and 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 toward a multi-protocol environment that includes OSI, and to support OSI it's 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 doc recommends a structure for the Domain Specific Part of NSAP addresses for use in the Internet that stays consistent with those principles ✨
"Representing Public Archives in the Directory", Wengyik Yeong, 12/04/1991.
there are tons of publicly accessible archives on the Internet now, and the gap between those archives existing and people actually knowing what's in them keeps getting wider 😭 it's also tricky to tell users how to retrieve them. so the Internet user community needs these knowledge gaps bridged if they're going to make good use of this class of resources 📚
"Schema for Information Resource Description in X.500", Chris Weider, 06/14/1991.
the authors want distributed access and updating for Information Resource Description information to be available to Internet users 🧚 this paper talks through the schema used to hold that info. the new attributes come from the US-MARC fields and subfields, with the mapping explained in the text 💅
"Schema for NIC Profile Information in X.500", Chris Weider, Mark Knopper, 06/14/1991.
the authors, working together with the chairs of the IETF Network Information Services Infrastructure (NISI) group, want to build a Directory of Network Information Centers, or NICs 🌈 this way NICs can find each other easily, users with access to a DSA can find out where the NICs are, and info about the Internet and some of its infrastructure gets spread around way more smoothly. this doc proposes a set of standard schema for this info 🫶
"Using the OSI Directory to Achieve User Friendly Naming", S. Kille, 01/30/1992.
the OSI Directory has user friendly naming as a goal, but simple-minded usage doesn't get there 💀 two things are missing: 1) A user oriented notation and 2) Guessability. this proposal sets out some conventions for representing names in a friendly way and shows how they can be used to get really friendly naming. that leads to a standard format for representing names and procedures to resolve them, so directory names can be passed between humans 👑 the format is identical to the one defined in the reference of "A String Representation of Distinguished Name", and these specifications are meant to be compatible 🔥
"Requirements for X.400 Management Domains (MDs) Operating in the Global Research and Development X.400 Service", R. Hagens, 11/12/1991.
this doc specifies a set of minimal operational requirements that must be implemented by all Management Domains (MDs) in the Global R&D X.400 Service 💖 it defines the core operational requirements, and in some cases the technical detail is handled by reference to other documents. the Global R&D X.400 Service is defined as all organizations that meet the requirements described here ✨
"Routing Coordination for X.400 MHS Services within a Multiprotocol/Multinetwork Environment", U. Eppenberger, 10/25/1992.
X.400 addresses are starting to show up on business cards 🎀 but the different MHS service providers aren't well interconnected or coordinated, so it's a super hard job for MHS managers to know where to route all the new addresses 😭 a big number of X.400 implementations support different lower layer stacks, and there are lots of large transport networks around. that means there's now a chance to build a worldwide message handling service using the same electronic mail standard, without needing gateways that reduce service and without being stuck on a single common transport network 🌍 this doc 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 docs 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 docs were prepared by the DOE GOSIP Migration Working Group and can be retrieved from the ESnet Information Server in directory [ANONYMOUS.DOE-GOSIP].
U.S. Department of Energy. Government Open Systems Interconnection Profile. Transition Strategy. DOE GOSIP Document # GW-ST-008. November, 1990.
U.S. Department of Energy. Government Open Systems Interconnection Profile. Transition Plan. DOE GOSIP Document # GW_PN_005. November, 1990.
U.S. Department of Energy. Government Open Systems Interconnection Profile. Procedures and Guidelines. DOE GOSIP Document # GW-PR-007. April, 1991.
IETF Working Groups 👑
three IETF working groups, OSI X.400, OSI-DS and MHS-DS, have been working in X.400 and X.500 💜 minutes of meetings, descriptions of the working groups' charters and goals, info about mailing lists, and other pertinent docs 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 🎀
okay bestie, this is the whole squad that made this happen 🫶 the Task Force members are listed below, and the contributing authors are marked so you know who really did the heavy lifting 💅
Bob Aiken 🌸 U.S. Department of Energy, Office of Energy Research, Scientific Computing Staff (now with National Science Foundation) Email: raiken@nsf.gov
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
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) 👑 the main character 👑 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
Security Considerations 🔒
okay this part is serious, so don't skip it 😭 security issues are discussed in sections 2.5.1 and 2.7.5.1 of this memo, so go check those out before you do anything else 🙈
⚠️ security is not the place to vibe-check. read sections2.5.1and2.7.5.1in full. periodt.
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
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 🫶
📦 where this page comes from
- ietf: rfc1330 1992-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms