RFC 1802

RFC 1802: Introducing Project Long Bud 🦋

Okay bestie, so this is RFC 1802 💖, and its title is Introducing Project Long Bud: Internet Pilot Project for the Deployment of X.500 Directory Information in Support of X.400 Routing 🎀. It was written for the Network Working Group and published in June 1995 🌈. It's Informational, which means it shares info with the Internet community and is not an Internet standard 💅. The authors are H. Alvestrand from UNINETT, K. Jordan from Control Data Systems, S. Langlois from Electricite de France, and J. Romaguera from NetConsult 👑. The title block doesn't list anything it obsoletes or updates ✨.

Status of this Memo 🌸

This memo gives info to the Internet community 💜. It does not specify an Internet standard of any kind 🙅. Distribution of this memo is unlimited 🦋.

Abstract 🧚

The Internet X.400 community (i.e., GO-MHS) doesn't currently have a distributed mechanism for dynamically updating and managing message routing info 😭. The IETF MHS-DS Working Group came up with an approach that lets X.400 Message Handling Systems do message routing using OSI Directory Services 🔥. The MHS-DS approach has already been tested successfully in a bunch of local environments ✨.

This memo describes a proposed Internet Pilot Project that wants to prove the MHS-DS approach on a much bigger scale 🚀. The results of this pilot will then be used to draw up recommendations for a global deployment 🌸.

1. Background 🍓

The 1988 edition of X.400 brought in, among other extensions and revisions, the idea of O/R Names 💅. That idea assumes a widely available Directory Service exists 🧠. This Directory Service is needed for several MHS operations, like supporting names that identify message senders and receivers in a user-friendly way, supporting distribution lists, authenticating MHS components, and describing what MHS components are capable of 🫶.

Lots of users were really excited about Directory Names because they meant they didn't have to remember complicated O/R Addresses for everyone they messaged 🥹.

Here's the tea 🍵: in the MHS infrastructure, a name by itself doesn't have enough info for Message Transfer Agents (MTAs) to route a message to the User Agent (UA) that serves that name. Compared to other protocols, that's a big difference 👀. Routing depends on info provided by different MHS Management Domains, whether they're public or private 💖.

An MHS community combines several administrative MHS domains that have agreements for cooperative routing with each other. The GO-MHS community is the set of MTAs handling X.400 mail operations on the Internet [RFC 1649] 🌐.

Without a distributed Directory Service, the GO-MHS community came up with an interim technique to collect and advertise routing info 🧚. That became an experimental IETF protocol [RFC 1465] 🧪.

2. Rationale 💜

A bunch of routing problems are stopping the current Internet X.400 service from growing its number of participating message transfer agents to a global scale 😤. The two most critical problems are:

• The current way of centrally maintaining and advertising MTA routing tables has already been optimized as much as possible 🙈. Adding more directly connected MTAs also adds more work for the MHS managers 😩. The current solution doesn't scale 📉. Routing needs to be a fully dynamic and distributed process 🌈.
• Manually propagating and installing routing tables doesn't guarantee consistent routing info (not even in a loose way) when different MTAs spread all over the globe access it 💀.

Everyone pretty much agrees that a distributed mechanism for dynamically updating and managing X.400 routing info is highly desirable 🫶. So the focus of this project is to set up X.500-based support for X.400 routing at a very large scale 🔥.

3. Benefits ✨

Using the Directory as a dynamic way to store and advertise info means participants in Project Long Bud can count on their updated data being available globally to the community 🌍. Because of that, a participating MHS manager gets to skip configuring connections to the other participants 🙌.

Directory-capable MTAs will be able to find more optimal and more direct routes to X.400 destinations than are practical today 🦋. That means faster message delivery 🚀.

Reliability gets a glow-up too 💖. The info stored in the Directory allows automatic use of backup connections when there's a problem with a remote MTA or the network 🛟. X.400 mail managers in the GO-MHS Community also get to stop worrying about the complexity of the whole mail routing infrastructure 😌. A dynamic routing infrastructure gets rid of the inconsistencies caused by unsynchronized static tables and improves quality of service 💅.

Beyond robustness and optimization of the new routing infrastructure, the Long Bud approach should give participating organizations better control over how they set up and maintain their interconnection with the GO-MHS community 👑.

Participants also get to help build an X.400 network that can grow to a very large scale 🌏. They'll get experience with a global messaging architecture that scales well and needs minimal administrative overhead 🧑‍💻. And they'll be able to talk about their experience with the MHS-DS experts and architects during the ongoing standards development cycle 🎀.

4. Definition of project LONG BUD 🌟

The Long Bud pilot wants to show that the X.500 Directory can provide a global-scale service to messaging applications 💜.

MHS-DS does offer ways to use private routing trees, but Long Bud is going to focus on the Open Community Routing Tree used by the GO-MHS community 🌳.

4.1 Project Goals 🎯

Project Long Bud has the following goals:

• Gather pilot experience with the defined framework for X.500 support of MTA routing, as defined by the IETF MHS-DS Working Group [Kille 94] 🧪.
• Actively look into moving the existing operational X.400 service from a routing method based on distributing centrally maintained static tables, as specified in [RFC 1465], to a method based on X.500 🚚:
  • Deploy X.400 MTAs that can directly read routing info from the X.500 Directory, following the specifications of the MHS-DS Working Group. This type of MTA is called a directory-capable MTA 🧚.
  • Deploy tools that read routing info from the X.500 Directory and use it to generate static routing tables for MTAs that are not directory-capable 🛠️.
• Specify a set of minimal operational requirements that need to be in place before X.500-based routing of X.400 messages can be widely deployed 📋.

4.2 Phasing 🌙

The first phase of Project Long Bud is about deploying a small number of directory-capable MTAs run by members of the MHS-DS Working Group and the GO-MHS community 🐣. These MTAs must be capable of using info in the X.500 directory to route messages to all the other members of the project, as well as to the existing GO-MHS community 📬. As of this writing, an initial set of MTAs is already operational 🥳.

At the end of this phase, the following goals should be achieved:

• The X.500 DIT must be populated with enough routing info for the participating MTAs to reliably route messages to each other and to the existing GO-MHS community 💌.
• The X.500 DSAs holding the routing info must run at a quality of service that's acceptable for an operational X.400 service 💅.

As a prerequisite, a sufficient number of MTA managers need to be willing to participate in Project Long Bud for the first set of results to be significant 🙋. Support for a protocol stack conforming to [RFC 1006] is mandatory 🔒. All MTAs participating in the Long Bud pilot need to register in the Open Tree and must be prepared to accept connections from anyone 🫣.

Note that in the first phase, default routes will be established in the DIT so that messages addressed to destinations outside the Long Bud community get routed to designated MTAs in the GO-MHS community ✨. This allows for full connectivity between the Long Bud community and the GO-MHS community, which are related but distinct communities 🤝. Interworking between these two must be established and coordinated 🧩.

In the second phase of Project Long Bud, a greater number of MTAs should be added to the experiment 📈. Cooperation with non directory-capable communities must be addressed 🌈.

4.3 General Approach 🧭

No large-scale resources have been committed to this project 😬. Still, expedient deployment is desirable 🏃‍♀️. So the pilot project needs to be focused and relatively short-lived ⏳. The general approach for meeting these requirements includes:

• Use as many existing MHS-DS tools as possible. Also, keep tracking the progress of tools being developed by project members, and help get them deployed as soon as they're ready 🛠️.
• Coordinate efforts with the existing GO-MHS community service 🤝.
• Set up a core infrastructure: 4 DSAs (two in the United States and two in Europe) are set up to serve MHS-DS information 🇺🇸🇪🇺.
• Wherever it's technically feasible, DSA managers will set up bilateral agreements with one (or more) of the core DSAs to duplicate their routing info 👯. For example, the core DSAs support the replication protocol specified in [RFC 1275] as a duplication technique 🔁.
• The Long Bud pilot needs to actively cooperate with DANTE NameFlow (the continuation of the PARADISE Pilot) and other directory providers to promote stability and consistency of information 💖.

4.4 Tools Needed ✨

Okay so, if we want MHS-DS routing tech to actually spread and have directory-capable MTAs and non-directory-capable MTAs vibing together, we need tools that do these three things 🔥:

• Populating the Directory with routing information 💖: this tool MUST accept routing information written in the standard syntax the GO-MHS community uses (see [RFC 1465]) as its input, and then it will load or update entries that carry that same info in the X.500 Directory.
• Downloading routing information from the Directory 🎀: so organizations not using directory-capable MTAs get a migration path, we need a tool that reads X.400 routing info from the X.500 Directory and generates static routing info from it. The static info it generates will follow the syntax the GO-MHS community defined, so "classical" MTAs run just as they currently do 🫶.
• Displaying the route a message takes between two end-points 🦋: this tool SHOULD accept two parameters as input: the X.500 distinguished name of an MTA, and an X.400 O/R name. It will display the possible routes that may be taken to deliver a message from the specified MTA to the specified X.400 destination. Honestly, it looks super similar to the traceroute facility used at the IP level 🌸.

These tools MUST use standard protocols to access the Directory (such as DAP [CCITT 88] or LDAP [RFC 1487]). Portability is encouraged 🧚.

A note on quality 💜

Pilot use of this Directory information depends heavily on data quality and availability 😭. Administering DSA availability and global Directory data accuracy are not in the scope of Long Bud, but care MUST be taken that the Directory resources used by Long Bud participants are administered well 💅.

If they've got the technical ability to do so, Long Bud participants are encouraged to replicate routing information in their Directory to improve data availability 🌈.

Directory data used by the pilot MUST be accurate: solutions to this problem will be suggested as the project matures ⭐.

---

5. Participation Guide 🎀

The existing operational X.400 service, the GO-MHS service, distributes and manages X.400 routing info like this: a group of MTAs gets organized into a routing community. The community keeps its routing info up to date by giving each MTA manager the job of working out the routing info for his/her MTA, formalizing it in the syntax the community defined, and sending the result to the GO-MHS coordination service. Once the info has been validated against the other data from all the managers in the community, the coordination service advertises it to the whole community. Then each manager has to update his/her MTA configuration with the verified info 💅.

The purpose of Project Long Bud is to let a manager operate an MTA without having to perform ANY manual steps whenever another MTA manager adds or changes routing info 🙌. This makes interconnecting very large communities of MTAs efficient, dynamic, and manageable ✨. It will help the Internet X.400 community get past the scalability limits it's running into right now 🚀.

5.1 Prerequisites for participation 💅

Okay, the prerequisites for joining Project Long Bud are:

Step 1: Participants in the pilot MUST have a good knowledge of the IETF MHS-DS Working Group activities and documents:

1. Participants MUST join the MHS-DS distribution list:

RFC-822:  mhs-ds@mercury.udev.cdc.com

  X.400:  PN=mhs-ds; OU=mercury; OU=OSS;
          OU=ARH; O=CPG; P=CDC; A=ATTMail; C=US

Requests to join the MHS-DS distribution list MAY be sent to the following email address:

RFC-822:  mhs-ds-request@mercury.udev.cdc.com

  X.400:  PN=mhs-ds-request; OU=mercury; OU=OSS;
          OU=ARH; O=CPG; P=CDC; A=ATTMail; C=US

2. Participants MUST retrieve and get familiar with all the relevant tools and documents stored on the Project Long Bud anonymous FTP server:

Host name:  ftp.css.cdc.com
Directory:  pub/mhs-ds/long-bud

In particular, openly available software related to Long Bud activities will be kept up-to-date at this location 🍓.

3. If not already done, participants MUST do one of the following:
   • Upgrade their X.400 and X.500 software so that it supports the MHS-DS specifications as in [Kille 94].
   • Use the tools which extract MHS-DS information from the directory and generate whatever local configuration files are necessary to allow local MTAs to use the information. This SHOULD be done frequently (at least once per day).

Step 2: Participants MUST register REQUIRED entries in the Directory so that their MTA(s) is (are) known to the Directory.

1. Arrange with the appropriate DSA Manager (who can be a local manager if the DSA is run by the participating organization, or a manager who is in charge of running the organization's DSA) to create an entry for the local MTA(s) involved in the pilot. At this stage, only connection information is REQUIRED.
2. Check, test and verify the connection information with at least one other participant. The mhs-ds distribution list SHOULD be used for announcing the new registration and asking for volunteers to test.
3. Participants MUST establish sensible default X.400 routes to existing GO-MHS destinations for which X.500-based routing information will not exist initially.

Step 3: Participants can then enter their routing information in the Directory.

1. Before any routing is entered in the DIT, participants MUST check with the GO-MHS Coordination Service that the routes they want to register can be properly handled by the GO-MHS community (contact information is mailflow@mailflow.dante.net). It is crucial for the Pilot that any routing information entered in the Directory is kept carefully accurate if the experiment is to be meaningful. Participants MAY also consider the need for mapping rules (see [RFC 1465] for details).
2. Once the above step is validated by the GO-MHS Coordination Service, participants MUST record routing information for their MTA(s) in the Internet X.500 directory service. This requires that a participant does the following:
   • Arrange with the appropriate DSA Manager (who can be either a local manager if the DSA is run by the participating organization, or a manager which is in charge of running the organization's DSA) to enter X.400 routing information in a routing tree held by the participating organization. This routing tree SHOULD contain all necessary information for the local mail domain.
   • Check, test and verify the registered routing information with at least one other participant. The mhs-ds distribution list SHOULD be used for announcing the new registration and asking for volunteers for testing.
3. If a participant adds new nonleaf entries to the Open Community Routing Tree, then s/he MUST find at least one other participant who will maintain a slave copy of the children of the nonleaf entry. Send an email to the mhs-ds distribution list to find a partner who is willing to do this.
4. If a participant adds new nonleaf ADMD or PRMD entries to the directory, then s/he MUST contact the managers of the Long Bud core DSA's and arrange to provide slave copies of the children of the ADMD and/or PRMD entries to all of the core DSA's. Send an email to the mhs-ds distribution list to contact the core DSA managers.
5. Once the above testing is completed, send an email to the mhs-ds distribution list announcing the establishment of new X.500-based routes 🎉.

---

6. Notes on side effects 🦋

The Long Bud Pilot Project, with its specific scope, is investigating a new direction in X.500 service usage. This should facilitate and expedite the global deployment of X.500 on the Internet 🌍.

Once the routing infrastructure illustrated by the Long Bud experiment is in place, the routing process will be able to take additional information into account to improve quality of service (minimizing message conversions, enforcing various security policies established by MHS domains, taking advantage of recipients' capabilities stored in the Directory, ...). While the Open Tree provides global connectivity, multiple private routing trees allow the use of various routing trees 👑.

7. Acknowledgements 💜

The authors would like to thank Urs Eppenberger (SWITCH) and Allan Cargille (University of Wisconsin) for their constructive comments on earlier drafts of this document 🫶.

8. Security Considerations 🔒

Security issues are not discussed in this memo. 💀 That's the whole section, no further details.

References

[CCITT 88] International Telegraph and Telephone Consultative Committee. X.500 Recommendations series. December 1988.

[RFC 1649] Hagens, R., and A. Hansen, "Operational Requirements for X.400 Management Domains in the GO-MHS Community", RFC 1649, ANS, UNINETT, July 1994.

[Kille 94] Kille, S., "MHS Use of the X.500 Directory to Support MHS Routing", RFC 1801, ISODE Consortium, June 1995.

[RFC 1006] Rose, M., and D. Cass, "ISO Transport Service on top of the TCP Version: 3", STD 35, RFC 1006, Northrop Research and Technology Center, May 1987.

[RFC 1275] Hardcastle-Kille, S., "Replication Requirements to provide an Internet Directory using X.500", RFC 1275, University College London, November 1991.

[RFC 1465] Eppenberger, U., "Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment Table Format V3 for Static Routing", RFC 1465, SWITCH, May 1993.

[RFC 1487] Yeong, W., Howes, T., and S. Kille, "X.500 Lightweight Directory Access Protocol", RFC 1487, Performance Systems International, University of Michigan, ISODE Consortium, July 1993.

Authors' Addresses ✨

okay bestie, this is the final stop! 🦋 these are the four legends who wrote this whole thing, so here's how to find them if you need to slide into their inbox 💌 they're literally iconic 👑

   Harald T. Alvestrand
   UNINETT
   P.O. box 6883 Elgeseter
   N-7002 Trondheim, Norway

   Phone:  +47-73-59-70-94
   EMail:  Harald.T.Alvestrand@uninett.no


   Kevin E. Jordan
   Control Data Systems, Inc.
   4201 Lexington Avenue North
   Arden Hills, MN 55126, USA

   Phone:  +1-612-482-6835
   EMail:  Kevin.E.Jordan@cdc.com


   Sylvain Langlois
   Electricite de France
   Direction des Etudes et Recherches
   1, avenue du General de Gaulle
   92141 Clamart Cedex, France

   Phone:  +33-1-47-65-44-02
   EMail:  Sylvain.Langlois@der.edf.fr


   James A. Romaguera
   NetConsult AG
   Morgenstrasse 129 3018 Bern, Switzerland

   Phone:  +41-31-9984141
   EMail:  Romaguera@NetConsult.ch
   X.400:  S=Romaguera;O=NetConsult;P=switch;A=arcom;C=ch

that's the whole doc, bestie 🫶💅🎀