RFC 1616

X.400(1988) for the Academic and Research Community in Europe

📅 published May 1994, from ietf

RFC 1616: X.400(1988) for the Academic and Research Community in Europe 💖

  • Who wrote it: a report by the RARE Task Force on X.400(1988), part of the RARE Working Group on Mail & Messaging. It's filed under the Network Working Group, as RARE WG-MSG Task Force 88 🦋
  • Editors: James A. (Jim) Romaguera & Erik Huizer 🎀
  • Category: Informational
  • Date: May 1994
  • Series: RARE Technical Report 10
  • Obsoletes or updates: the title block doesn't list any RFCs it obsoletes or updates ✨

Status of this Memo 📜

Okay bestie, this memo is just information for the Internet community. It does not specify an Internet standard of any kind 🫶 Distribution is unlimited 🌈

1. Abstract 💅

So the European R&D community, through the member research networks of RARE, has basically led the way in rolling out X.400 electronic messaging services across the global R&D world. They used the international recommendations CCITT X.400(1984), and they've been doing it for more than five years 🔥 Serving European R&D users made it super obvious that there's a big, growing demand for new and enhanced electronic messaging services and products. People want to talk inside the R&D community, but also with commercial service providers and organisations too 👑

New services like Multimedia messaging and Secure messaging are giving major benefits 🤩 They're not just for R&D either, but for the wider commercial, industrial and public communities. They open up innovative ways of working and living that can only make the missions and goals of those communities better. Getting globally pervasive messaging between all users, R&D and commercial alike, is way easier when people adopt these advanced services early. Think about it: in lots of organisations (especially commercial ones), messaging might be the only way to communicate with independent organisations, because of security considerations and lower layer network differences 😭

The CEC VALUE subprogram II was set up to support initiatives on developing and adapting R&D networks in member states 🧚 Among other things, VALUE supports X.400 initiatives in certain countries. So far its support has been limited to X.400(1984), since that's been the dominant OSI service up until now. But X.400(1988) implementations are starting to show up, so a VALUE funded study of the X.400(1988) aspects of messaging, and how they'd affect the R&D community, was felt to be necessary. This report is one of the results of that study 💜

The report documents the results of a task force on X.400(1988) deployment, run by the RARE Mail and Messaging Work Group from November 1992 until October 1993. Open reviews of the report happened in the RARE Mail and Messaging Work Group and within the IETF X.400ops Working Group 🦋

The scope is limited to deploying X.400(1988) services, so the report has no recommendations on developing and deploying Internet RFC 822 / MIME / PEM related (pilot) services. But since the report shows that both X.400(1988) and RFC 822 / MIME / PEM will be developed and used within the European R&D community, such a pilot should also be considered. ✨

Note: RFC 822 is also known as Internet STD 11. 🎀

Circulation of this report is unlimited 💌 Comments on it can be sent to the e-mail distribution list:

RFC 822: wg-msg@rare.nl
X.400:   S=wg-msg;O=rare;P=surf;A=400net;C=nl;

Task Force Members 🌸

  • Claudio Allocchio (INFN)
  • Harald T. Alvestrand (SINTEF)
  • James C. I. Craigie (JNT)
  • Urs Eppenberger (SWITCH)
  • Frode Hernes (maXware)
  • Jeroen Houttuin (RARE)
  • Erik Huizer (SURFnet) - chairman
  • Steve Kille (ISODE Consortium)
  • James A. (Jim) Romaguera (NetConsult)

Editors: James A. (Jim) Romaguera & Erik Huizer 👑

The work of this Task Force has been funded by the Commission of European Communities (CEC) VALUE subprogram II, Stichting SURF and SURFnet bv. 🍓

Table of Contents 📚

   1.  Abstract                                                      1
   2.  Management Summary                                            3
   3.  Framework for the report                                      6
   4.  Present situation of European Messaging                       7
      4.1. Messaging services                                        7
      4.2. Requirements for messaging                                8
             4.2.1. User Oriented                                    9
             4.2.2. Service provider viewpoint                      10
      4.3. Messaging capabilities                                   11
   5.  Possible solutions for providing globally pervasive
       messaging                                                    12
      5.1. PC LAN E-mail systems                                    13
      5.2. RFC 822, MIME and PEM services                           15
      5.3. X.400 - 1984 and 1988                                    19
   6.  Migration to X.400(1988)                                     23
      6.1. PC LAN E-mail systems                                    25
      6.2. RFC 822, MIME and PEM services                           25
      6.3. X.400(1984) services                                     27
      6.4. Mail-11 services                                         28
   7.  Benefits of migrating to X.400(1988) and the involved costs  28
   8.  Main Recommendations                                         33
   9.  Security Considerations                                      34
   10. Reading List and Bibliography                                35
   11. Terminology                                                  37
   Appendix A - Elaboration on the main recommendations             38
   Appendix B - A number of detailed guidelines.                    40
   Authors' Addresses                                               44

2. Management Summary 💖

okay bestie, this doc is the receipts on X.400(1988) and how it hits the R&D community 🧚💅 The study was funded by the CEC under VALUE Subprogram II and a task force on the RARE Mail Working Group did the work ✨ It's aimed at technical decision makers and whoever's gonna fund stuff in this area 🫶

The doc lays out the current situation for the messaging tech that's basically running Europe 👑 It looks at it through a few big messaging communities that use these technologies:

  • RFC 822,
  • X.400(1984),
  • Mail-11 and
  • PC LAN messaging

There are also three major European communities being referenced:

  • Commercial service providers
  • R&D community
  • Commercial organisations using messaging services.

The report states these facts 🔥:

  • Running multiple wide area messaging services that connect independent organisations takes a lot of people and money. So it's desirable to keep the number of those services as low as possible 💀 This is true for the R&D community, and it's also highly likely to be true for European industry in general.
  • There are two publicly available technological standards that open communities can use, like the R&D community and public service providers: the X.400(1984 and 1988) recommendations and the Internet RFC 822 / MIME / PEM standards 🦋
  • There's an established, very large global user base for Internet RFC 822 and X.400(1984) messaging. Both have their own momentum in different parts of the user community, and both are still developing and growing fast 🌸

The report concludes that X.400(1988) will be the preferred protocol for inter-organisational connection for European industry, government, and parts of the European R&D community. RFC 822 / MIME / PEM will be the preferred protocol suite for inter-organisational connection in the Internet community. Since products are already widely available, it's also the preferred protocol for parts of the European R&D community 💜

The goal of European pervasive messaging, which brings together Industry, Government and Academia, would be best served by a single messaging service. However, that's not feasible, because X.400(84 and 88) and RFC 822 (and MIME) based services are gonna be around for a long time to come 😭 So to increase the functionality of Wide Area E-mail services, there's a clear need to:

  • migrate RFC 822 services to an RFC 822 / MIME / PEM service. A MIME based service gives the user more functionality than a plain RFC 822 service 🎀
  • migrate existing X.400 services to an X.400(1988) service.

Because X.400(1984) doesn't scale well in terms of extra functionality, it's gonna get harder and harder to meet the needs of research users on existing X.400(1984) services unless an X.400(1988) service is put into place 💀

  • provide a transparent gateway between X.400(1988) and RFC 822/MIME/PEM. For the European R&D community this is essential, so the two services can connect with maximum functionality ✨

Such a gateway is technically feasible, and it's an essential part of a unified E-mail service. Without a standardised gateway, the overall E-mail service would deteriorate 😩

The lack of open standards for PC LAN messaging systems discourages their use as 'backbone' messaging technologies in open communities. But the products these systems deliver to end users mean their already large share of the messaging market will keep existing for some time 👑 So it's also essential to put strategies in place that let these systems be 'seamlessly' integrated into the global messaging community. Since the main messaging vendors are developing X.400(1988) and RFC 822/MIME gateways, a strategy to link these systems together via X.400 and RFC 822 should be developed 🧚

The report ends with a set of recommendations. The main one is establishing an X.400(1988) European pilot messaging service for the R&D community, and this pilot should include a transparent gateway service between X.400(1988) and RFC 822/MIME 🌈 The goal of a European pilot is to make sure a European-wide operational X.400(1988) service actually gets deployed, one that's pervasive and meets user needs. By gathering the issues around setting up a European X.400(1988) service, this report acts as a focal point and stimulant for discussion in the R&D community 💖 It also presents a summary of the benefits and problems of each of the messaging technologies above, in the context of a global messaging service of which R&D is one part. It identifies issues, strategies and recommendations for migration and coexistence of these technologies, mainly within the European R&D community but also in relation to other messaging communities. A cost / benefit analysis of a European-wide X.400(1988) pilot messaging service is included as well. Finally, a reading list of references on the subject has been compiled 📚

The report does not include any recommendations on developing and deploying RFC 822 / MIME / PEM related (pilot) services, since those are outside the scope of the Task Force. But because the report shows that both X.400(1988) and RFC 822 / MIME / PEM will be developed and used within the European R&D community, such a pilot should also be considered 🫶

3. Framework for the report 🎀

So the belief behind all this is that user demand for new messaging services, like Multimedia and Secure Messaging, would grow 🦋 The RARE community (together with other communities, most notably the Internet Engineering Task Force (IETF)) has been experimenting with new messaging and related technologies over the past few years ✨ There have been experiments and pilots in messaging services, e.g., as recommended by CCITT X.400(1988), and in Directory Services based on the CCITT X.500(1988) recommendations 🌸

The results of these pilots and experiments show that now is the right moment to start a pilot X.400(1988) messaging service for the European R&D community 🔥 The major goals of the pilot are to:

  • establish a large scale European wide pilot messaging service based on X.400(1988).
  • collaborate with and help start similar pilot services in different communities, both R&D and non-R&D (e.g., commercial ADMDs and PRMDs, etc.), and both European and non-European (e.g., North American, Asian, etc.).
  • encourage and assist the development and deployment of a wide variety of commercial and public domain X.400(1988) messaging products that meet users' needs. Examples are User Agents (UAs), Message Stores (MSs), Message Transfer Agents (MTAs) and gateways between X.400(1988) services and other widespread messaging services, i.e., RFC 822, Mail-11 and proprietary ones 💅
  • prove that such a service and its products efficiently meet the existing and expected demands of European R&D users. And from that, determine the steps for a European deployment of an operational X.400(1988) messaging service 👑
  • determine the steps needed to migrate the existing operational R&D X.400(1984) based messaging service (represented by the R&D MHS service, formerly COSINE MHS), the RFC 822 / MIME / PEM based messaging services, and the HEPnet / SPAN Mail-11 based messaging service to an operational X.400(1988) messaging service. Obviously, during these migrations, transition steps must be included that allow a period of coexistence, at the highest possible service level, between X.400(1988), X.400(1984), RFC 822 / MIME and HEPnet / SPAN Mail-11 services 😭
  • determine the steps needed to integrate proprietary messaging systems, which are widely deployed within the European R&D community, at as high a service level as possible through an X.400(1988) infrastructure 🧚

This report identifies the issues involved in such a pilot service. It is not a concrete proposal for such a project. Instead, it discusses advantages and disadvantages, costs and benefits, and migration issues for deploying an X.400(1988) service. So basically it's a discussion and feasibility paper on creating a large scale European wide pilot X.400(1988) messaging service for the European R&D community 💖

4. Present situation of European Messaging 🌈

4.1. Messaging services ✨

Okay so, electronic messaging within Europe is basically a bunch of messaging services communities 💬, kind of like friend groups that all text each other 🫶. Three important communities make up the scene:

  • Commercial e-mail networks,
  • Research e-mail networks and
  • PC LAN messaging systems.

Commercial e-mail networks are classified as either ADMDs or PRMDs 💅. ADMDs and PRMDs are operating in nearly every European country 🌍.

  • ADMD services (or public commercial e-mail services) are provided by over 50 service providers that have interconnected using the X.400(1984) protocols. The topology between these ADMDs is not yet 'mesh', but it's progressing quite rapidly toward that optimum goal 🚀. Still, there's a way to go before ADMDs provide full European connectivity 🥹.
  • PRMDs (or private commercial e-mail service providers) have interconnected to ADMDs and to other PRMDs, mostly using the X.400(1984) protocols but also with proprietary protocols 🎀.

Research networks are providing messaging services in every European country 🔬. These R&D service providers operate as either ADMDs or PRMDs, and they use both X.400(1984) protocols and Internet RFC 822 protocols to connect to each other 🦋.

Then there are also big R&D communities (i.e., HEPnet and SPAN) using proprietary protocols (i.e., DECnet Phase IV and Mail-11) as their main messaging systems 🧚. The DECnet IV based communities are now migrating to DECnet Phase V (OSI connectionless protocol stack), which provides X.400(1988) (plus X.400(1984)) as a major messaging system ⭐. Overall, all these services are totally interconnected. So it's a statement of fact that the European R&D community has two parallel interconnected messaging infrastructures, one based on X.400(1984) and one based on RFC 822 👑. The catch is that interconnections between the R&D messaging community and most of the European commercial service providers use the X.400(1984) protocols 💀.

The commercial world mostly makes inter-organizational messaging interconnections using the X.400(1984) protocols 💼. And the commercial messaging world is not as totally interconnected as the R&D messaging community 🙈. Finally, a number of commercial and public organisations often have a mandatory requirement to use X.400 for messaging interconnections 📋.

The usage of PC LAN messaging systems is increasing very rapidly within the academic and commercial communities 📈. In general, PC LAN messaging services in both communities don't use X.400(1984) or RFC 822 messaging systems. They run on systems based on proprietary protocols instead 🫠. PC LAN messaging systems can be considered more as 'Islands of Messaging' that gateway to the commercial and R&D messaging services by using X.400(1984) or RFC 822 gateways 🏝️. PC LAN messaging systems within commercial organisations also connect to commercial service providers via proprietary protocols 🔒. The PC LAN messaging services probably comprise the largest number of users, but they're generally poorly integrated with the global messaging service 😭 (The Dutch, UK and Italian academic communities confirm that there appears to be many such 'Islands' of PC LAN messaging systems within their networks.).

4.2. Requirements for messaging 📝

Experience with existing global e-mail services has proven that as messaging use grows, people become aware of extra requirements for related services 📈. These requirements can be classified into 'User based Requirements' and 'Service Provider based Requirements', and both exist to either support or exploit high quality messaging services ✨. We'll go through them in this chapter 🎀.

4.2.1. User Oriented 🙋‍♀️

Honestly, the only thing a user really requires is an easy to use, well integrated, user interface to electronic mail 💖. Usually the user doesn't care what protocol is used 🤷‍♀️. There are still certain inherent requirements to the functionality, though, and these can be identified as user requirements. The main user requirements identified are:

  • Distribution Lists (DLs): X.400(1984) got a lot of side-eye for leaving out DL support 👀. Distribution lists let users enlist themselves onto electronic mail expander lists (distribution lists). A message sent to such a list is automatically, and without significant delay, passed on to anyone whose electronic mail address is on it 📬. A list can be a public one meant for discussing a specific subject, kind of like a sort of "magazine" 📰. It can also be a "closed" list, containing only a selected set of people who need to communicate privately, e.g., a project-team 🤫.
  • Multinational language and Multimedia support: European users have been frustrated for years by not being able to use their national character sets when messaging 😤. Under the hood, the e-mail problems causing that character set frustration are basically the same problems that would get in the way of Multimedia messaging, like:
    • lack of binary data support
    • lack of standardised encoding schema's
    • definition of multiple body-parts

The massive potential of Multimedia systems and services is a huge deal 🌈. The commercial community is hyped about it (we've seen the enormous press publicity and mega-mergers positioning companies to exploit this tech), and so are government spheres like the U.S.A. Government's 'Information Superhighway' initiative 🛣️. All of that has pushed rapid progress in solving these problems 🚀.

  • White pages Directory Service: A white pages directory service is a unique but very basic and important service 📖. It's a way to store and find information about people and resources, kind of like the paper White Pages of a telephone service 📞. User e-mail addresses can be stored there for later retrieval by e-mail systems 💌.
  • EDI: EDI isn't really used much in the academic environment right now 🧐. But there's a distinct potential within the academic community to reduce costs and improve services with EDI 💸. Potential EDI uses could be:
    • EDI between universities
    • EDI between universities and government
    • EDI between universities and lower level educational institutions (e.g., student records)
    • Commercial EDI using the Internet as an infrastructure.

Maintaining end to end integrity (especially the security aspects) of EDI messages is a big deal, so it mandates that no gateways should be used between originator and recipient 🔐.

  • Support of Security services: E-mail as it's currently used is far from secure 😬. To allow for serious usage of E-mail, security issues need to be addressed, like:
    • integrity; making sure that the message is transferred intact, without any changes or additions.
    • encryption; making sure the message content is only decipherable by the intended recipient.
    • authentication; making sure that the originator and/or recipient are authenticated.

4.2.2. Service provider viewpoint 🏢

The task force believes the following points are the most significant service provider requirements 👑:

  • Network Management: This area is still very new when it comes to offering standardised protocols, services and products for management 🆕. Still, a minimum 'goal' is to provide central management functions that let providers offer a better quality of service 🎯. There's ongoing work within the IETF Working Group MADMAN to define SNMP monitoring and managing of E-mail systems, gateways and X.500 directory systems 🛠️. A number of management areas still need work, including: QOS, Service Level Agreements (SLAs), Multiple system queue management, Accounting, Routing Co-ordination and Message Tracing 📊.
  • Support of MTA routing: Dynamic routing from MTA to MTA takes away the need to maintain large routing tables 🗺️. That matters most within a large PRMD, or a community of PRMDs (like the R&D MHS community) 🌸.
  • Address mapping between RFC 822 and X.400: Using X.500 or DNS for mapping cuts the manpower needed to centrally coordinate globally consistent X.400-to-RFC-822 mapping tables 🧮. It also spreads out responsibility for updating the mapping rules 🤝. This should let mapping rules change when needed and be available immediately ⚡.
  • UA capabilities registration: Using the directory to register UA capabilities for X.400(1988), X.400(1984) and RFC 822 / MIME / PEM systems is a very desirable benefit for users 🌟. It helps speed up the deployment of new messaging services (e.g., Multimedia Messaging) 🚀.

4.3. Messaging capabilities 💅

okay so, multi-protocol gatewaying is a total mess 😵‍💫, which is why most R&D E-mail users are stuck with InterPersonal Messaging (IPM) services that only swap message body parts in CCITT character set IA5 (US ASCII). Bestie, that's giving plain-text-only energy 📄.

Within the R&D community, recent work on non ASCII messaging services (the stuff we covered above) has led to upgrades for messaging based on RFC 822 protocols ✨. Those upgrades bring Multimedia support through the Multipurpose Internet Mail Extensions (MIME), and secure messaging through Privacy Enhanced Mail (PEM), which is coming very soon 🔐. MIME-enhanced RFC 822 services are already rolling out: software is being distributed and the needed organisational structures are being set up 🚀. PEM is in a large scale pilot phase, e.g., the VALUE PASSWORD project 🧪.

For X.400(1984), non ASCII body parts are mostly used through a bilateral agreement between recipient and originator, using body part 14 🤝. In practice, that means non ASCII body parts can only be exchanged when the recipient and originator share the same bilateral agreement, or when the originator includes an ASCII message explaining the content type they're sending 🙃. Besides IPM, EDI on top of X.400(1984) is growing in use 📈.

With all those X.400(1984) deficiencies in mind, the CCITT / ISO specified X.400(1988) to meet new user demands 👑. X.400(1988) supports various different body parts, enhanced security features, international character set support and support of X.500 Directory Services 🌈. Since these standards could meet user needs for new messaging services, the R&D community has been experimenting with and piloting X.400(1988) and X.500(1988) services 🧚. X.400(1988) messaging depends heavily on X.500(1988) directory services, so the necessary precondition is a deployed and operational X.500(1988) directory service 🫶. Piloting and deploying the X.500(1988) directory service within the R&D community has been successfully started and co-ordinated by the COSINE and the VALUE PARADISE projects 🎀.

Secure messaging has been tackled similarly by the VALUE PASSWORD project and the RARE and IETF communities 🔐. Work on directory support for X.400(1988) messaging has been done within the IETF and RARE. The relevant RARE and IETF work groups (e.g., RARE WG-MSG, IETF MHS-DS, etc.) have also worked to produce any needed enhancements to the base X.400(1988) and X.500(1988) standards 🛠️. Last but definitely not least, X.400(1988), compared to X.400(1984), gives a comprehensive basis for gatewaying to and from RFC 822 / MIME / PEM and PC LAN messaging services 🌉. The IETF has defined standards for gatewaying Multimedia mail between RFC 822 / MIME / PEM and X.400(1988) ✨. Now that RFC 822 / MIME / PEM is being deployed on the Internet, deploying X.400(1988) services is needed to ensure multimedia and secure messaging connectivity for the European R&D community 🇪🇺.

5. Possible solutions for providing globally pervasive messaging ✨

okay so, when you line the present situation up against user requirements, it's pretty clear that current messaging services just don't match what users need 😭. To try to fix that, a bunch of developments are happening across different messaging technology areas. Because of the installed user base within the R&D community, these areas are considered relevant:

  • PC LAN E-mail systems such as Lotus cc:Mail, Microsoft Mail and Novell MHS
  • RFC 822 / MIME / PEM E-mail services
  • X.400(1988) messaging services

Ongoing developments in each of these areas give the R&D community new messaging options 🌸. How well each area can solve problems for user and service provider requirements is summarised in this chapter 📝.

5.1. PC LAN E-mail systems 🖥️

Right now, PC LAN E-mail systems are mostly used for internal communication inside an organisation 🏢. External connections, if there are any at all, to public service providers or other organisations usually go through gateways to X.400(1984) or RFC 822 🚪. Using a PC LAN E-mail system as infrastructure for interconnecting E-mail systems of different hues isn't common within the Research community 🙅. Recent experience from, among others, the Dutch Research network - SURFnet - [14] and the Norwegian Directorate for Public Management - Statskonsult - [18] has shown that a number of problems (i.e., limited functionality, high operational management cost, etc.) can be expected should these PC LAN E-mail systems be used as an E-mail infrastructure 😬. (Using native X.400 protocols for PC LAN E-mail systems would avoid gateways and would thus ease many of these problems 💡.) Here's a summary of those problems and some relevant issues:

  • Interconnecting heterogeneous PC LAN messaging systems: one very distinct benefit for E-mail users of all hues is the potential to integrate heterogeneous PC LAN messaging systems with a minimum loss of service (e.g., multimedia services) by connecting them via X.400(1988) (or RFC 822/MIME/SMTP). X.400(1988) is already being used, or is under active development, for connecting PC LAN messaging systems together in a number of environments (e.g., Apple Macintoshes, DEC, Microsoft, Lotus, etc.). This tendency to gateway PC LAN messaging systems via X.400(1988) will increase, and it's one of the benefits X.400(1988) brings to global multiprotocol messaging 🌍.
  • Multimedia and binary data support: the benefit of E-mail systems using these PC LAN systems is that the user interfaces are usually well integrated into the user's standard working environment 💻. Using a proprietary protocol, these systems allow not only text (ASCII) but also binary, word processor, video, audio and other types of files to be transported 🎞️. To reap the benefits of this multimedia / binary data transfer, it would normally require that the same type of gateway is used by sender and receiver. Transporting these same files to another type of PC LAN E-mail system is not possible through the current gateways without some information loss 💔. In effect, PC LAN E-mail system's X.400 (or RFC 822) gateways from different vendors perform acceptably only for text body parts. True heterogeneous multimedia PC LAN messaging needs gateways to X.400(1988)'s service 🫧.
  • Application Programming Interfaces: to help solve the problem of portability for Mail Enabled Applications, Microsoft, Lotus, Novell, XAPIA and X/OPEN have been working on a number of standards for the Application Interface to mail transport protocols (i.e., Mail Application Programming Interface - MAPI, Vendor Independent Messaging - VIM, Common Mail Calls - CMC) 🧩. These efforts are structured independently of the existing 'Wide-Area' or inter organisational E-mail protocols of X.400(1984) and RFC 822. However, the MAPI, VIM and CMC efforts, due to their proposers (respectively Microsoft, Lotus and X/OPEN), do look like they'll be the stimulant that gets various software developers building more portable applications 🚀. They also look like they'll let the rich functionality of X.400(1988) be accessed by these applications, which would reduce the need for gatewaying to X.400(1988) 👏.
  • Security: as PC LAN E-mail systems require gateways for connectivity, they pose a problem with regard to encrypted messages 🔒. Gatewaying of secure messages is normally not possible. The gatewaying of secure messages is a general problem of gatewaying from one mail system to any other system, and it is not specific to PC LAN E-mail systems 🙃.
  • Directory Services: to date, mostly proprietary directory services have been deployed, and they don't match what users need in terms of access controls for data that's distributed and decentralised across organisations 📇. X.500 based services promise solutions to such needs, so various suppliers have announced support of X.500 directory services for their E-mail products 🎉. However, should these interfaces be delayed, then support of an inter organisational 'White Pages' service requires either:
    • directory information exchange products (i.e., directory gateways) deployed between a proprietary system and an X.500 directory system
    • gateways between de-facto market based proprietary standards, such as Retix Directory Exchange (DX) or Soft*switch's Directory Synchronisation (DS), and X.500 protocols
    • duplicated directories, i.e., one proprietary and one X.500 need to be operated

It's worth stressing that gatewaying mechanisms and products are often problematic because of the lack of an open standard on the proprietary messaging system and/or directory system 🙈.

As an aside, it is thus essential to establish an operational X.500 infrastructure, including E-mail user interfaces that can transparently access this Directory Service, as soon as possible 🚨.

5.2. RFC 822, MIME and PEM services 💌

okay so RFC 822 messaging is everywhere in the R&D community 🧚 and people are still actively extending it so it can meet what users actually need. a few of those extensions get the spotlight in this chapter, so let's go 💅

Distribution lists 📋

RFC 822 lets you use DLs (distribution lists), but managing them isn't standardised yet, so it's kinda a wild west rn 🙈

RFC 822 multimedia messaging via MIME 🎨

so once MIME showed up, RFC 822 got a second standard that handles multimedia messaging SO well 😭 for users, MIME means message body parts can use multinational character sets and even binary data, and a message can have multiple body parts too 🌈 the real icon move is how it works. MIME just overlays its services on top of the existing RFC 822 service, so it doesn't require any changes to the RFC 822 infrastructure already in place 🫶 which seriously simplifies the MIME deployment. that's the cleanest glow-up ever ✨

RFC 822 secure messaging via PEM 🔐

just like MIME brought multimedia to RFC 822, Privacy Enhanced Mail (PEM) is bringing secure messaging to RFC 822 services 💖 PEM uses the same overlay trick as MIME: it layers its services on top of the existing RFC 822 services without changing the RFC 822 infrastructure. PEM gives RFC 822 users confidentiality and integrity of messages. BUT (and this is a big but 😭) a number of problems with PEM, and X.400(1988) as well, still need to be solved before secure messaging can be considered an operational service. these problems don't depend on whether you're using PEM or X.400(1988), and they're mostly about distributing secret keys to end users. there's very active work going on within the IETF to solve them, so stay tuned 👑

MIME and PEM 🎀

so there are still issues for messages that are a multimedia message (MIME) and a secure message (PEM) at the same time 🙃 a PEM encoded MIME message doesn't allow gatewaying to other messaging environments, so none of the features inherent in MIME can be exploited along the message path. a MIME message that contains PEM encoded body parts can be gatewayed, but then the integrity of the entire message isn't guaranteed.

⚠️ this is a real deficiency of both existing approaches, because users really need to be able to use multimedia and secure messaging at the same time 💀

once again, the IETF is working super hard on this, and solutions can be expected. the gatewaying of PEM messages to other E-mail systems is still unclear though 🥺

Dynamic and distributed messaging routing via the Domain Name System (DNS) 🗺️

RFC 822 messaging gets a huge assist from having a dynamic, distributed way to help with routing: the Domain Name System (DNS) 🌍 with DNS support, RFC 822 MTAs can route directly to other RFC 822 MTAs and deliver messages with a minimum of delay ⚡ in practice, mail still often goes through multiple RFC 822 MTAs for reasons like Mail Hubs (for users who turn their machine off when they go home), Firewall Hubs (for security reasons), etc. but it's commonly accepted that delivery between RFC 822 mail hubs is super fast. routing decisions typically resolve in less than one minute and very often within seconds ⏱️ overall, the DNS is a really valuable service that works well in practice 💅

Support for Character sets 🔤

together with the MIME specification for content types, an extension for RFC 822 headers was defined that allows for multiple character sets in names, subject etc. in RFC 822 headers [9]. this means (European) users can use their preferred character set for their language, not only in the message contents but in the headers too 🇪🇺🌸

MIME capable gateways 🌉

to give everyone a seamless service, whether they're on RFC 822 or X.400, a widely available set of well run and standardised RFC 822 to X.400 gateways must be in place. for InterPersonal Messaging (IPM) based on US ASCII, there are already a large number of standardised (i.e., X.400-to-RFC 822) gateways deployed. to ensure seamless gatewaying between MIME and X.400 multimedia users, these existing text based gateways must be either upgraded to or replaced with multimedia messaging gateways. a bunch of proposed Internet standards to solve this, for both X.400(1984) and X.400(1988), came out of the MIMEMHS work group of the IETF and have been completed [4] 🎉

Access to fax, teletex, telex or physical delivery 📠

for the moment, there's no standardised way for RFC 822 users to access gateways to these services, except indirectly through X.400(1988) systems (concatenated gateways: RFC 822 to X.400(1988), then onward to the appropriate X.400(1988) Access Unit) 📨 even this indirect method would need some further work on standardising mappings between RFC 822 addresses and X.400(1992)'s X.121 addresses. some experiments in the RFC 822 world are also happening on routing fax messages 🖨️

Operational support 🛠️

RFC 822 messaging services are generally delivered on a best effort basis, so service level agreements asking for stringent response times to operational problems or guaranteed delivery times are difficult to agree on 😬 this phenomenon might be a result of the distribution and delegation of authority to organisations updating the RFC 822 MTA's routing mechanism, i.e., DNS. as a result, it's hard to reach a one stop shopping agreement for RFC 822 messaging services 🛒

Notifications 🔔

the RFC 822 service gives users a minimum amount of base protocol support. you could argue that keeping RFC 822 this simple means the software implementing it can be smaller and easier to build 🧸 but features like delivery & receipt notifications and UA capabilities registration would be commonly accepted as desirable from a user standpoint, so they'd be desirable extensions to RFC 822 💖 some operational problems relating to reliability could be minimised by technology with standardised support for positive and negative notifications of messages. compared to X.400, RFC 822 technology doesn't yet support positive notifications (although work is starting within the IETF to extend RFC 822 to support delivery notifications 👀). however, within the RFC 821 transport system (i.e., SMTP), there are standardised negative notifications that work well 👍 alternatively, X.400 technology deployed over TCP/IP (using STD 35, RFC 1006) may help address the lack of adequate service quality, meaning the notification support, when using E-mail within the Internet 🌐

Portability of RFC 822 products 📦

there are only a few mailbox formats in general use by RFC 822 software: one is the bin/mail format and the other is the MH format 📂 this 'standard' mailbox format is a definite benefit for RFC 822 users, because it lets them change RFC 822 UAs (e.g., upgrading to MIME RFC 822 UAs) without compromising or converting their existing archived mail, which may comprise 1000s of archived messages 🥹

System support for RFC 822 products 💻

normally, RFC 822 MTAs and UAs come pre-installed on UNIX workstations, so users are spared the effort of installing RFC 822 MTA software 🙌 if a user or mail administrator wants to install a different MTA or UA than the pre-installed system, there's a large number of easily available (i.e., widely distributed amongst many FTP and other information servers) public domain RFC 822 MTAs and UAs 🗂️

both of those points encourage the spread of, and ease the installation of, software for the RFC 822 messaging service, and in many ways explain the size and importance of the installed base of RFC 822 systems 📈 to show how big the RFC 822 / MIME product world is, here's a non-comprehensive list of available MIME enhanced RFC 822 products: ELM 2.4, MH 6.8, Sun Mailtool, HP Mpower Desktop, Lotus cc:Mail (unconfirmed), Zcode Zmail, Frontier Super-TCP for Windows, PMDF (VAX VMS), Pine, C-Client (library routines), Metamail (viewer only), Andrew-MIME gateway. that's a whole lineup 💅

UA capability registration 🗃️

the IETF MHS-DS working group has defined how X.400 and RFC 822 User Agent capabilities can be stored in X.500 directory services 📚 this work is still ongoing 🚧

5.3. X.400 - 1984 and 1988 💌✨

okay so X.400(1988) is basically the glow-up of X.400(1984) 💅 a bunch of new stuff got added. here's the tea on the most important features of X.400 - 1984 and 1988 🎀

  • Notifications 🔔

okay so X.400(1984) gives you four notifications: positive and negative delivery notifications and positive and negative receipt notifications 📬. these let users make sure a message actually got delivered or that it was read 👀. service operators also use the delivery notifications in their fault escalation procedures 🚨.

  • Binary Data Transfer 💾

X.400(1984) lets binary data be transported without needing character encoding first 🙌. being able to transfer files of literally whatever type is such a valuable end user service 💖. and since there's no character encoding needed, users can use the received data without needing any character decoding software 🧚.

  • Multiple Body Parts 📎

sending multiple body parts within one message means users can send multiple logical components in one message 🍓. it's a natural mechanism for users because it mirrors real life, where you can send a letter, a word processor file, a spreadsheet file, etc. all in one message 💌.

  • Feature rich messaging model 🌈

X.400's features are very rich 🤩. that's a win for users because vendors can build applications that use these extensive features in an interoperable manner, since the features are standardised within X.400 ✨.

  • Clear messaging model 🗺️

X.400(1984), as one of its most wide reaching achievements, popularised a consistent and clear model for describing message handling systems across the market 👑. breaking a message handling system down into UAs, MSs, MTAs, MTS - ADMDs and PRMDs and Access Units / Gateways has proved to be an extremely useful tool for users and vendors to understand and communicate their messaging needs or solutions 💅.

  • Multiple lower layer networks 🧱

X.400 has embraced the concept that there are different technology lower layer networks 🦋. this even allows multiple logical networks of the same technology to be supported. X.400 lets the messaging service fully function even though the underlying network is varying 🫶. in the real world of a non-uniform network layer, this is an extremely powerful capability 💪.

here's the list of the major X.400(1988) extensions to X.400(1984) 📜:

  • Distribution Lists (DLs) 📮

a powerful mechanism for arbitrarily nested Distribution Lists, including the ability for DL owners to control access to their lists and to control the destination of non delivery reports 🙈. the current endemic use of DLs in the R&D community makes this a fundamental requirement for any service 💖. X.400(1988) uses X.500 to provide standardised support for DLs, although there have been some needed standardised enhancements relating to the CCITT defined DLs by the IETF MHS-DS work group 🛠️. the powerful nesting capabilities, plus management mechanisms for DL owners within X.400(1988) DLs, are features that give attractive benefits to users and DL managers ✨. there is already 'running code' 🏃‍♀️ via the COSINE Explode project, which is implementing the MHS-DS based enhancements. the project builds upon experience gained within a number of networks, e.g., JNT, and provides:

  • implementation of MHS-DS enhancements related to the X.400(1988) DLs
  • archiving of messages received by a DL.
  • access by users to the DL archive via e-mail.
  • subscription to a DL by users via e-mail.
  • Message Store (MS) 🗄️

The Message Store provides a server for remote UAs on workstations and PCs, enabling messages to be held for their recipient, which solves the problems of non-continuous availability of such UAs 🌸. the message store lets mobile workers, small offices and local schools become active messaging users in a cost effective manner 🎒. it also provides powerful selection mechanisms that let the user pick which messages get transferred between the store and the workstation 👀. this facility is not catered for adequately by the P3 protocol of X.400(1984), and it provides a major incentive for transition 🦄.

  • X.500 Directory names 📇

support for Directory Names in MHS will allow a transition from use of O/R addresses to Directory Names when X.500 Directories become widespread 🌍, thus removing the need for users to know about MHS topological addressing components 🙌.

the ability for X.400(1988) messages to contain directory names instead of O/R addresses is a powerful feature 💅. it frees users from the necessity to insert O/R addresses containing routing information, but lets them insert the more natural directory names. however, managing the large amounts of distributed data contained within the directory is problematic, in that it involves a number of organisational issues and not just software issues 😬. a number of X.400(1988) UAs which allow users to insert directory names instead of O/R addresses have already been developed 🎉.

  • Support for EDI 🧾

through the definition of Pedi, as defined in X.435, X.400(1988) offers integrated support for EDI messaging 💼. the CEC TEDIS program has mandated X.400 as the main carrier for EDI, and standardised how EDI transactions are inserted into X.400 messages (i.e., Pedi and P2) 📦. this provides a strong incentive to offer native X.400(1988) services to users and applications, encouraging commercial EDI traffic to migrate to X.400(1988) 🚀.

  • Secure Messaging 🔐

the provision of secure messaging services, including authentication, confidentiality, integrity and non-repudiation, as well as secure access between MHS components, are important benefits for the R&D community 🫶. the base standards are adequate for security, however organisational and software issues still need to be solved 😤. organisational issues of globally scaling the distribution of secret keys are still unsolved 🗝️. software issues of how end users will be able to comfortably and securely input secret keys of length 512 -> 1024 bits into security software still need to be solved 💀.

  • Multimedia 🎬

the definition of a number of additional body parts, plus the ability to define new body parts (e.g., Word Processor formats, Excel documents, etc.), provides the basis for multimedia services over X.400(1988) 🎞️. as well, the newly defined General Text body part supports multinational character sets (except for ISO 10646) without the need for transmission encoding 🌏. however, unlike MIME, X.400(1988) is only specifying a standard for multimedia messaging 🤔. to achieve multimedia document exchange, a further text exchange standard such as ODIF, Hytime, etc., is needed 📚.

  • Character set support for extended addressing 🔤

a highly desirable potential benefit for European R&D users is the extended character set support (i.e., T.61) within addresses 🇪🇺. nearly all European languages, except for Greek and Cyrillic, are supported by the T.61 teletex encoding 🥖. further extensions to X.400 for support of extended character sets have been defined by the RARE WG on character sets and RARE WG on messaging [15] ✍️.

  • Physical Delivery Services 📬

this standardised method for a message to be delivered on a physical medium, such as paper, through the normal postal service is useful when trying to reach a very wide number of (non-electronically reachable) recipients 🌾. in effect this service gives an ability to 'go the last mile' and communicate with users previously not easily reachable, e.g., farmers, etc. 🚜.

  • General Extension Mechanism 🧩

one of the major assets of X.400(1988) is the extension mechanism 💎. this is used to carry most of the extensions defined in these standards, but its principal benefit will be in reducing the trauma of transitions to future versions of the standards 🥹.

provided that implementations of the X.400(1988) standards do not try to place restrictions on the values that may be present, any future extension will be relayed by these implementations when the extension is not critical, thus providing a painless migration to new versions (1992 and beyond) of the standards 🦋.

  • UA Capability Registration 📝

with the extra functionality available to X.400(1988 and especially 1992) UAs (i.e., extra non-IA5 body parts, secure messaging, etc.), it is expected that the demand to register UA capabilities will increase 📈. in that respect, X.400(1988)'s ability to query X.500, where such capabilities would be stored, is a significant potential benefit for users 🌟.

  • X.500 support for MTA routing 🛣️

the piloting of X.500 to support MTA routing within the R&D community has already commenced, on a small experimental scale, via the Longbud project co-ordinated by the IETF MHS-DS work group 🧪. some concrete benefits promised by X.500 based routing are:

  • routing based upon content types, security, transport stacks and other criteria allows optimum routing paths to a destination MTA to be chosen. (There is presently no such similar capability within the DNS). 🤷‍♀️
  • allowing the routing information to be inserted and modified in a distributed manner reduces (if not eliminates) the necessity of central distribution of static routing tables. The consequent reduction in manpower to co-ordinate MTA routing, plus the increase in scalability of the service, allows a truly global messaging service to be put in place. 🌎✨

6. Migration to X.400(1988) ✨

okay so after everything we've covered, a few things are SUPER clear 💅

  • The people and the money needed to run multiple wide area messaging services that connect separate organisations are a LOT. So it's really desirable to keep the number of these services as low as possible 🫶 This is true for the R&D community, and it's also very likely true for European industry in general.
  • There are two publicly available technology standards that open communities can use, like the R&D community and public service providers: the X.400(1984 and 1988) recommendations, and the Internet RFC 822 / MIME / PEM standards 🦋
  • RFC 822 and X.400(1984) messaging services have an established, HUGE global user base. Both have their own momentum in different parts of the user community, and both are still developing and growing fast 🚀

so from all that, the infrastructure services that open communities have to support, especially the R&D community, are RFC 822 / MIME / PEM, X.400(1984), and X.400(1988) 💖 X.400(1988) will be the preferred protocol for connecting between organisations for European industry, government, and parts of the European R&D community. RFC 822 / MIME / PEM will be the preferred protocol suite for connecting between organisations for the Internet community. And since products are already widely available, it's also the preferred protocol for parts of the European R&D community 🌸

the dream of European pervasive messaging, with Industry, Government, and Academia all together, would be best served by ONE messaging service 🧚 BUT, taking everything above into account, that's not feasible, because X.400 and RFC 822 based services are going to be around for a long time 😭 So if we want to boost the functionality of Wide Area E-mail services, we clearly need to:

  • migrate RFC 822 services over to an RFC 822 / MIME / PEM service. A MIME based service gives the user more functionality than a plain RFC 822 service ✨
  • migrate existing X.400 services over to an X.400(1988) service. X.400(1984) doesn't scale well when it comes to extra functionality, so it's going to get harder and harder to meet the needs of research users of existing X.400(1984) services unless an X.400(1988) service is put into place 🍓
  • provide a transparent gateway between X.400(1988) and RFC 822/MIME/PEM. For the European R&D community, a transparent gateway between the X.400(1988) service and the RFC 822 / MIME / PEM service is essential, so the two can connect with maximum functionality 🎀

such a gateway is technically feasible, and it's an essential part of a unified E-mail service 💅 Without a standardised gateway, the overall E-mail service would get worse 💀

the lack of open standards for PC LAN messaging systems puts them off being used as 'backbone' messaging technologies within open communities 🙈 BUT the products these systems give end users keep their already big share of the messaging market going for some time. So it's also essential to put strategies in place that let these systems be 'seamlessly' integrated into the global messaging community 👑 And since the main messaging vendors seem to be developing X.400(1988) and RFC 822/MIME gateways, a strategy to link these systems together via X.400(1988) and RFC 822/MIME should be developed 🔥

to make migration to an X.400(1988) service feasible, we need to develop extensive migration and coexistence options for the various non-X.400(1988) users 🌈 The main issue in every migration strategy is still getting the users on board 🫶 The migration has to be user-driven. In other words, users need to be convinced that the added functionality is worth the cost of moving to X.400(1988) 💜 A detailed summary of the different issues and possible problems involved in moving to an X.400(1988) based messaging service is presented in this chapter, covering the four most important messaging services that are commonly accepted: RFC 822, MIME and PEM; X.400(1984); MAIL-11; and PC LAN messaging systems ✨

6.1. PC LAN E-mail systems

for coexistence and migration, gateways are totally unavoidable 🦋 The quality of these gateways has to get better in these areas:

  • Transparency (gatewaying multimedia messages, transparent addressing)
  • Manageability
  • Reliability

ultimately, through the use of APIs like MAPI and CMC, the users' interface will hopefully become independent of whichever mail protocol is being used 🧚 That would mean users can keep the mail user interface they prefer, while the protocol underneath migrates to X.400(1988) 💖

via these APIs, it may be possible to access the full features of X.400(1988) while still keeping a proprietary PC LAN UA 👑 That way, a PC LAN can be easily connected to an X.400(1988) backbone. Using APIs to make migration easier for end users should be encouraged 🫶

the migration of PC LAN E-mail systems will most likely be driven by the commercial vendors of mail-enabled applications, like UAs, Work Group Systems, and Task Flow Systems, plus X.400(1988) MTAs and gateways that can serve these applications through the new APIs 🌸

6.2. RFC 822, MIME and PEM services

a migration from RFC 822 / MIME and PEM services to X.400(1988) needs to be worked out for the management domains that want to make this change 🍓 A long term transition and coexistence phase also needs to be planned for, because there's already a big existing base of RFC 822 users 😭 Understanding the issues involved in moving from RFC 822 to X.400(1988) messaging services is essential before any sensible decisions about migration can happen 🤓 Certainly one of the main issues (if not THE main issue) is that the migration must allow a transition period where maximum functionality exists between both services 🔥 And any migration has to keep in mind that RFC 822 messaging services are a 'moving target' 🎯

  • Ease of transition, as an RFC 822 user sees it, means the user's existing mail folders must be converted flawlessly into the new mail product's folder system 💅
  • An RFC 822 user's e-mail address should stay the same even after a migration. In other words, the user keeps the same address, which has two different notation forms: X.400 and RFC 822 ✨
  • Users thinking about migrating will be encouraged to do it if they don't lose any service when it comes to MIME and X.400(1988) gatewaying, they can still put RFC 822 style addresses into the X.400(1988) UA, and they get high performance X.400-to-RFC 822 gateways 🦋
  • The extra connectivity from X.400(1984 or 1988) gateways to fax, telex, post, and so on, plus the additional X.400 users they can easily reach (without losing connectivity to RFC 822 addresses), plus the extra functionality of X.400(1988) when talking to X.400(1988) users, will also be a nudge towards migrating 🎀
  • The RFC 822 / MIME products set the bar that an RFC 822 user will compare any X.400(1988) product against 👑 So X.400(1988) products must provide some basic and important functions, like: Character Set support via GeneralText; Multimedia capability via Extended Body Parts; low message delays on the scale of seconds; and easy product configuration 💖 Right now, there's no RFC 822 equivalent of X.400 delivery and receipt notifications, so users see these functions as extra functionality 🌈
  • Following on from the extra functionality point above, present RFC 822 users, most likely commercial users, who want to use EDI or other mail-enabled applications that need security, message audits, and positive confirmations, will be encouraged to migrate to X.400(1988) 🔥 Choosing X.400(1988) in this case would be especially attractive for commercial RFC 822 users who already run multiple lower layer networks. Since X.400(1988) easily accommodates multiple different network layers, the cost to migrate could be considered quite small 💜

6.3. X.400(1984) services

a number of problems can be spotted in a migration from X.400(1984) to X.400(1988) 🙈 They can be summed up like this:

  • OSI supporting layers are mandatory in the ISO10021 MOTIS standard, but support for the complete OSI stack (normal mode) is optional in the otherwise equivalent CCITT X.400(1988) specifications 😳 So it's recommended that the migration from X.400(1984) should go straight to ISO 10021, i.e., straight to using the full OSI stack with normal mode RTS 🧚
  • There's a negative impact on quality of service caused by implementation decisions related to the 'General Extension Mechanism'. To overcome this negative impact, no minimal X.400(1988) MTAs should be used. Those are MTAs that relay the syntax but understand none of the semantics of extensions 💀
  • All X.400(1988) MTAs should generate reports containing the extensions that were present in the original message, and route those reports through the DL expansion hierarchy where appropriate 🎀
  • Choosing standards for mixed X.400(1984 and 1988) management domains needs to account for two things. In one option, there's the danger of undetectable routing loops caused by incorrectly configured routing entries. In the other option, there's the problem that systems which have fixed the routing loop problem may not all be implemented consistently, because the standards have ambiguities. The choice of which of these two options a management domain uses internally has no impact on external management domains 🌸
  • DDA support is needed by X.400(1984) systems so they can address X.400(1988) Common Name Attribute users [2] 💖
  • To keep loss of service quality to a minimum, downgrading X.400(1988) body parts to X.400(1984) body parts should be done according to the MIMEMHS specifications [4] 🍓
  • To improve connectivity to both X.400(1984 and 1988) management domains without degrading X.400(1988) service, management domain entry points that support both X.400(1984 and 1988) are recommended 🦋
  • Making sure that no X.400(1988) MTAs transit via X.400(1984) MTAs. This allows no degradation of X.400(1988) service quality [17] 🔥

the consequence of that last point is that the existing European Research X.400(1984) MTA RELAY backbone, formerly known as COSINE MHS, should be one of the first MTA communities to migrate to X.400(1988) 👑🌈

6.4. Mail-11 services 📬

Okay bestie, so Mail-11 (aka DECnet mail) 💖 is the main e-mail service used in the High Energy Physics and Space Physics Analysis Networks (i.e., HEPnet and SPAN). It's the native e-mail service on VMS operating systems, and the big HEPnet / SPAN community considers it the most popular service out there 🔥. Mail-11 also comes with big, easy-to-use gateways to other e-mail protocols, like X.400 (84), RFC 822 (SMTP over TCP/IP, DECnet and X.25, BSMTP over NJE), and PC LAN E-mail services ✨.

Okay, plot twist 🙈: along with the "old style" Mail-11 UA, the DECnet Phase V (OSI CLNS) service natively runs X.400 (88) and X.400(1984) services. So X.400 (88) could show up as soon as the HEPnet / SPAN community migrates to DECnet Phase V. BUT the VMS based UAs for X.400(1988) are still super limited, so people are kinda stuck on their Mail-11 UA (and therefore the Mail-11 service) 😭.

HEPnet / SPAN users are literally begging for upgrades that support multimedia and delivery / read receipt services 🫶. That's a huge push for good X.400(1988) UAs to show up soon, so users can actually use the X.400(1988) service that DECnet Phase V already offers 🦋.

7. Benefits of migrating to X.400(1988) and the involved costs 💸

Real talk: how much you actually gain from moving off your current mail system to a new mail protocol depends SO much on good products, a well-organised migration, and a real commitment that the switch is worth the cost 💅. Quantifiable and accurate cost / benefit ratios aren't possible within the decentralised European R&D environment, so none are generated 🙈.

In this chapter we listed the benefits that a migration to X.400(1988) achieves, and gave an indication of the relative costs too 🎀. As long as there are good products, and you also take the recommendations of Chapter 8 and Appendices A and B into account, the task force is confident these potential benefits will turn into actual benefits and be worth the costs 🌈.

Benefits

Here's the list of non-technical benefits, plus the X.400(1988) features that make each one happen ✨. The benefit of,

  • efficient and innovative communication within Europe is helped along by setting up an X.400(1988) messaging service that integrates European industry, government and academia 🌸
  • an increase in business efficiency through EDI (like automatic processing of business forms and exchange of business contracts) gets a glow-up from the security aspects of X.400(1988), i.e., non-repudiation, authentication, confidentiality, integrity plus secure access between MHS components 🔐
  • letting European users communicate in their native European languages is made possible by the GeneralText body part of X.400(1988) 🗣️
  • remote users and Small and Medium size Enterprises (SME) using e-mail for electronic commerce are encouraged, because the entry level costs for e-mail go down. An SME's use of Remote UAs together with a service provider's MS, instead of buying their own MTA, is accommodated by X.400(1988) 💼
  • providing global messaging for all e-mail users, while still recognising the existing market realities of heterogeneous e-mail systems, is boosted by setting up gateways to X.400(1988) 🌐
  • being able to recover costs by charging and accounting for messaging services back to users (super important for commercial service providers) is made possible by the message auditing capabilities of X.400(1988) 💰
  • communication with users who have no access to E-mail (for example, if such users are defined within Distribution Lists) is improved by X.400(1988)'s support for gateways to physical delivery, fax, telex, teletex, etc. 📠
  • building on the existing X.400(1984) infrastructure (which means lower establishment costs) happens by migrating the X.400(1984) infrastructure to X.400(1988) 🏗️
  • a cut in manpower (and therefore costs) to manage a global messaging service comes from the service's ability to use the global distributed directory for management information 📚
  • the messaging infrastructure can meet new user requirements thanks to support for the General Extensible Mechanism 🧩
  • making E-mail more user friendly comes from a messaging service that lets you use more natural directory names in E-mail addresses 💌
  • more effective messaging through DLs comes from X.400(1988)'s support for powerful nesting capabilities and management for DLs 🎯
  • a boost in global message delivery performance and reliability is helped along by X.400(1988)'s ability to use X.500 for MTA routing 🚀
  • more messages getting delivered to mobile or transient users is enhanced by the provision of the Message Store 📱
  • multimedia use is enhanced by the ability to define new body parts and to support multiple types of binary data, like audio and video 🎶
  • optimum and seamless message conversion based on each user's capabilities comes from the ability of X.400(1988) to act upon UA capabilities 🧚

Costs

The generic costs to establish an X.400(1988) pilot service can be broken down into:

  • a cost per backbone of RELAY MTAs (as used by the European research community - the former Cosine MHS service)
  • a cost per service provider
  • a cost per organisation
  • a cost per user
  • a cost per user MTA for migrating to X.400(1988)

To bring about the benefits mentioned above, certain costs will be incurred, and they're summarised below 🧾:

  • Cost per backbone of RELAY MTAs (as used by the European research community - the former Cosine MHS service)
    • The equipment costs of migrating backbone RELAY MTAs.
    • The establishment of some sort of organisational / project group to oversee a backbone RELAY MTA pilot.

As most of the RELAY MTAs are already X.400(1988) capable, there is already an MHS Co-ordination service in place that could be used for this function. The number of backbone RELAY MTAs is less than 100, so the cost for migrating the RELAY MTA backbone is considered relatively low 🧁.

  • Cost per service provider
    • If the RELAY MTA backbone (formerly Cosine MHS) is migrated towards X.400(1988), then the remaining cost for a service provider to migrate the infrastructure towards X.400(1988) is relatively low.
    • The operational costs for organisational issues, for example dealing with OID registrations, are low if national R&D service providers act as a clearinghouse for their own national R&D institutions, e.g., Universities.
  • Cost per organisation, end user and MTA
    • The operational costs of migrating end users and their MTAs in management domains to X.400(1988) are higher than the costs involved with migrating the infrastructure. This is due to the order of at least 10 to 100 times more MTAs, as compared to the service providers, that would be involved with a migration to X.400(1988). As the infrastructure needs to migrate first, the costs for the end user MTAs can be reduced by profiting from the migration experience of the service providers.
    • The education and training costs for users and system managers are significant, due to the amount of end users and end user MTAs. Any marginal cost savings per user which can be made, e.g., by deployment of automated tools, should be considered due to the large overall savings that accrue.
    • The costs of any potential disruption of the end user's messaging service are high, due to the huge numbers of end users involved, and as such only a very well managed, phased and planned migration should be considered.
  • Software costs
    • The costs for software development are outside the scope of this report. However, it is clear that cost needs to be incurred in order to provide software that is easy to install and use. As a result of the work of the task force, a list of possibly needed components and likely changes to existing components can be proposed,
      • Modifications, but not new developments, to software for:
        • X.400(1988) MTAs, X.400(1988) UAs, DSAs, DUAs and MSs.
      • New software developments for:
        • MIME to MHS Gateways, X.400(1988) network management, mailbox conversion, PC LAN directory synchronisation, PC LAN gateways and UA capability registration.
    • The distribution costs for any new software (for the European R&D community) are low if usual academic distribution methods (FTP servers, E-mail Based servers, Gopher, World Wide Web and Archie) are used.

Summary

Migration towards an X.400(1988) service needs to evolve from the inside (the messaging backbone) outward (to the end user MTAs and end users themselves) 🌷. Due to the numbers involved, both the costs and the benefits of the migration increase as it evolves towards the end users.

The benefits of migrating to an X.400(1988) service are a feature rich, well defined open standard with high functionality, scalability, use of directory, multimedia and secure messaging capability 💜. The costs for migrating a RELAY MTA backbone can be considered relatively low, whilst the migration of end user MTAs and the migration of the end users themselves are relatively high. These costs should, of course, be balanced against the cost of a disrupted service that one might get if no migration occurs at all and the current service (e.g., X.400(1984)) reaches the limits of its scalability and/or functionality ⚖️.

It's important to realise that if end users themselves don't experience direct feedback of the benefits from X.400(1988), it may make the organisational motivation needed for the migration difficult to achieve 😤. In effect, the establishment of a pilot X.400(1988) service is and should be driven by the requirements of end users, so achieving end user benefits (as listed above) must be given a higher priority within an X.400(1988) service than solely the extra service provider benefits 👑.

8. Main Recommendations ✨

Okay bestie, so the RARE WG-MSG Task Force on 'The Establishment of an X.400(1988) Pan European Pilot Messaging Service' came up with a bunch of high level recommendations for setting one of these up 🧚. The main ones are listed in this chapter. Appendix A goes deeper into each one and is written for policy makers who want more background 💼. Appendix B is a list of very detailed guidelines, plus some issues that still need further investigation 🔍. If you're a technical person who wants nitty gritty guidance that lines up with the main recommendations, Appendix B is your new best friend 💖.

Recommendations

  • Set up an X.400(1988) pilot service that covers European commercial, government and academic bodies 🌍. It should be co-ordinated through an industry forum where all the parties can meet 🤝. Using an existing forum where user organisations are well represented is desirable if commercial end users' requirements are going to be met ✨. That forum should also be open to non-European participants 🌸.
  • X.400(1988) end user services should be provided, along with an X.400(1988) backbone RELAY MTA service inside the pilot 💅. End user services get top priority 👑.
  • Help the X.400(1988) product market, which is already emerging, to thrive by making sure there's a steady supply of high quality X.400(1988) public domain software 🛠️.

The Internet has proven that public domain software, free of any commercial restrictions, is rapidly developed further by Small and Medium Size Enterprises (SMEs) into derivative products that suit the commercial market 🦋.

  • Any pilot should be well co-ordinated and results driven, but it should use a distributed, market oriented approach 🎯. Trying to organise and plan such a pilot under the assumption of a single centrally funded body, i.e., driven from the 'top', is considered very difficult 😵. A more 'market driven' or distributed organisation is considered feasible and likely to succeed if all the market 'players' are fully involved, i.e., a 'bottom' up approach 🌱.
  • For the academic community, and even more so for the commercial community, there is a business need to ensure near total and 'perfect' integration with the existing and also evolving RFC 822 based services 🔗.
  • For the academic community, a rapid migration of the existing X.400(1984) backbone RELAY MTAs (used within the European R&D X.400(1984) service, formerly the COSINE MHS service) is considered urgent 🚨. This migration gives academic organisations a 'bootstrap' path to internationally pilot X.400(1988) services 🥾. End user piloting is not considered feasible if X.400(1984) backbone RELAY MTAs are used for an X.400(1988) service (see Reference [17] for technical details) 🙅.

The report does not include any recommendations on development and deployment of RFC 822 / MIME / PEM related (pilot) services, since those are outside the scope of the Task Force 🙈. However, since both X.400(1988) and RFC 822 / MIME / PEM will be developed and used within the European R&D community, such a pilot should also be considered 💜.

9. Security Considerations 🔒

Okay, this one is seriously important, so listen up 😭. Security issues are not discussed in this memo. Not one word 💀. Please don't assume this document has your security covered, because it literally doesn't 🫠.

10. Reading List and Bibliography 📚

This section has a list of relevant reference documents for further reading, so go down that rabbit hole 🐇.

[1]         Kille;, S., "Mapping between X.400(1988) / ISO 10021
            and RFC 822", RFC 1327/RTR 2, University College
            London, May 1992.

[2]         Kille, S., "X.400 1988 to 1984 downgrading",
            RFC 1328/RTR 3, University College London, May 1992.

[3]         Adie, C.,  "A Survey on Multimedia Projects, Products
            and Standards", RTR 5, Edinburgh University Computing
            Centre, January 1993.

[4]         Alvestrand, H., and S. Thompson, "Equivalences between
            1988 X.400 and RFC 822 Message Bodies", RFC 1494,
            SINTEF DELAB, Soft*Switch Inc., August 1993.

[5]         Alvestrand, H.,  Kille, S., Miles, R., Rose, M.,
            and S. Thompson, "Mapping between X.400 and RFC 822
            Message Bodies", RFC 1495, SINTEF DELAB, ISODE
            Consortium, Soft*Switch, Inc., Dover Beach
            Consulting, Inc., Soft*Switch, Inc., August 1993.

[6]         Alvestrand, H., Romaguera,  J., and K. Jordan,
            "Rules for downgrading messages from X.400/88 to
            X.400/84 when MIME content-types are present in the
            messages", RFC 1496, SINTEF DELAB, NetConsult AG,
            Control Data Systems, Inc., August 1993.

[7]         IETF MHS-DS Working Group, Works in Progress.

[8]         Borenstein, N., and N. Freed, "MIME (Multipurpose
            Internet Mail Extensions) Part One: Mechanisms for
            Specifying and Describing the Format of Internet
            Message Bodies", RFC 1521, Bellcore, Innosoft,
            September 1993.

[9]         Moore, K., "MIME (Multipurpose Internet Mail
            Extensions) Part Two: Message Header Extensions for
            Non-ASCII Text", RFC 1522, University of Tennessee,
            September 1993.

[10]        Kaliski, B., "Privacy Enhancement for Internet
            Electronic Mail: Part IV: Key Certification and
            Related Services", RFC 1424, RSA Laboratories,
            February 1993.

[11]        Balenson, D., "Privacy Enhancement for Internet
            Electronic Mail: Part III: Algorithms, Modes, and
            Identifiers", RFC 1423, TIS, February 1993.

[12]        Kent, S., "Privacy Enhancement for Internet
            Electronic Mail: Part II: Certificate Based Key
            Management", RFC 1422, BBN, February 1993.

[13]        Linn, J., "Privacy Enhancement for Internet
            Electronic Mail: Part I: Message Encryption and
            Authentication Procedures", RFC 1421, IAB IRTF PSRG,
            IETF PEM WG, February 1993.

[14]        Jurg, P., and E. Huizer, "The SURFnet electronic mail
            project", SURFnet, EH/PJ932307, July 1993.

[15]        Alvestrand, H., "X.400 Use of Extended Character
            Sets", RFC 1502/RTR 7, SINTEF DELAB, August 1993.

[16]        Manros, C.-U., "The X.400 Blue Book Companion", ISBN
            1 871802 00 8, Technology Appraisals Ltd, 1989.

[17]        Houttuin, J., and J. Craigie, "Migrating from
            X.400(1984) to X.400(1988)", RFC 1615/RTR 9,
            RARE, JNT, May 1994.

[18]        Nagelhus, I. et al., "Survey of E-mail systems with
            X.400 capability".

[19]        "A White Paper on X.400(1988)", EMA Report.

[20]        IAB, IESG, "The Internet Standards Process --
            Revision 2", RFC 1602, March 1994.

11. Terminology 💅

Here's the glossary, bestie, with every acronym you're going to bump into 🎀.

ADMD     Administration Management Domain
ASCII    American Standard Code for Information Exchange
ASN.1    Abstract Syntax Notation One
AU       Access Unit
CCITT    Comite Consultatif International de Telegraphique et
         Telephonique
CEN      Comite Europeen de Normalisation
CENELEC  Comite Europeen de Normalisation Electrotechnique
CEPT     Conference Europeene des Postes et Telecommunications
CONS     Connection Oriented Network Service
COSINE   Co-operation for OSI networking in Europe
DL       Distribution List
DIS      Draft International Standard
EMA      Electronic Messaging Association
EN       European Norm
ENV      Draft EN, European functional standard
IEC      International Electrotechnical Commission
IETF     Internet Engineering Task Force [20]
IPM      Inter-Personal Message
IPMS     Inter-Personal Messaging Service
IPN      Inter-Personal Notification
ISO      International Organisation for Standardisation
JNT      Joint Network Team (UK)
JTC      Joint Technical Committee (ISO/IEC)
MD       Management Domain (either an ADMD or a PRMD)
MHS      Message Handling System
MHS-DS   Message Handling Systems use of Directory Service
         Working Group from the IETF
MIME     Multi-purpose Internet Mail Extensions (extensions to
         RFC 822) [6]
MOTIS    Message-Oriented Text Interchange Systems
MTA      Message Transfer Agent
MTL      Message Transfer Layer
MTS      Message Transfer System
NBS      National Bureau of Standardization
OSI      Open Systems Interconnection
PEM      Privacy Enhanced Mail [10]
PRMD     Private Management Domain
RARE     Reseaux Associes pour la Recherche Europeenne
RFC      Request For Comments (series of Internet publications)
RFC 822  RFC describing Internet Message format for Electronic
         mail
RTR      RARE Technical Report (series of RARE publications)
RTS      Reliable Transfer Service
WG-MSG   RARE Working Group on Mail and Messaging

Appendix A - Elaboration on the main recommendations ✨

okay so this appendix is the deep dive 🫶 where we get into the nitty gritty of the report's main recommendations. let's gooo 💖

  • okay bestie, for a globally pervasive messaging service, it's recommended to set up a well operated Pan-European X.400(1988) pilot backbone 🌍 made of MTAs and MSs. it connects partners from Industry, Commercial Service Providers, Academia and Public Bodies (CEC, National Governments, etc.) 🎀 and the pilot should be open to global participation 💅.
  • if we want the widest connectivity with the highest possible functionality 🦋, gateways should be installed that connect X.400(1988) and RFC 822/MIME. these gateways should follow the specifications of RFC 1327 [1] and RFC 1494 et al. [4]. the experience from these gateways should be fed back into the appropriate RARE and IETF Working Groups to improve the standards 🧚.
  • so the 'business needs' of non-R&D organisations can get in at an early stage 🌸 and the pilot's success can be measured and shared. to get non-R&D orgs actively participating in the pilot, it's recommended that an open forum comprising industry, service providers, public bodies and academia should be used. preferably an existing forum where end users are heavily involved is desirable 👑.
  • for meaningful co-operation between the bodies affected by the pilot (and fewer unnecessary duplications, hello efficiency 🙌), it's recommended that there are close liaisons and contacts between at least the IETF, RARE, EARN, EUnet, RIPE, Y-NET, EEMA, EMA, EWOS, OIW, CEN/CENELEC, ISO, CCITT, CEC and European governmental bodies and those involved within the pilot. the suggested way to make a meaningful liaison is for enough participants of the above organisations to attend the common forum mentioned above. it's also suggested that as much as possible e-mail distribution lists be used to communicate between forum participants 📬.
  • so the pilot can have measurable results 📊, it's recommended that the pilot shall be implemented in phases. it's considered that at least two phases are needed:
    • phase 1 - initial short start up phase with a small number of participants. the result of this phase is that any needed procedures, co-ordination mechanisms, etc. are put into place for the large scale piloting of phase 2 🌱.
    • phase 2 - phase with a wide Pan-European participation. the result of this phase should be a proof of scaling of the pilot X.400(1988) service, i.e., the goals of the pilot as defined in Chapter 1 are met 🏆. it's expected that once this phase is successfully completed, a natural evolution to a global deployment of an X.400(1988) service will have started 🚀.
  • to rapidly complete phase 1 of the pilot, and to keep the pilot at least Pan-European in scope 🗺️, it's recommended that: a number of R&D service providers, one each from several European countries; at least 2 North American R&D service providers; at least 1 Japanese R&D service provider and a small number of commercial service providers and commercial organisations are actively involved in phase 1 🫶.
  • to get an economically viable market place for X.400(1988) products (i.e., MTAs, UAs, etc.) going (i.e., users are willing to purchase such products) 🛍️, it's recommended that a suitable minimum number of new software implementations and/or modifications to existing software implementations be funded. the resulting software should be inserted into the Public Domain, free of any financial restrictions on further commercial exploitation. this way, Small and Medium Size Enterprises (SMEs) will be encouraged to commercially exploit such products 💅.
  • because the R&D community has such a strong influence on the pilot, plus everyone wants standardised products out the door quickly and pragmatically ⚡, it's recommended that any standards proposed within the scope of an X.400(1988) pilot (for example, standards re: character sets and body parts gatewayed to and from X.400(1988) and RFC 822 / MIME) are conformant to and candidates for Internet standardisation. as a concrete example of the standardisation process, this means that at least two independent software implementations, for each product category (of which one product preferably in the Public Domain), must be proven as interworking to a proposed standard before the proposed standard can be elevated to draft standard [20] 🔥.
  • to make sure there's a market driven demand for X.400(1988) products in the commercial market place 💼, it's recommended that the maximum number of Public Domain implementations funded by any one public funding organisation is two. it's desirable that at least one other product, preferably commercially based and not within the Public Domain, is produced 🌈.
  • so any information needed for the effective operation of the X.400(1988) pilot (not least OID assignments, mapping rules, information about interconnection partners, naming authority information) can be made widely available 📚, it's recommended that an electronically accessible information base be established 💜.
  • so any organisational issues needed for a deployment of an X.400(1988) service have a body in place to deal with them 🧸, it's recommended that the pilot either identifies and lists which bodies are responsible for which issues, or else actively ensures that a suitable body is being put in place 🙈.

Appendix B - A number of detailed guidelines. 🍓

okay, the Task Force has these detailed guidelines, and they're giving very specific main character energy 👑:

Product and operational service guidelines

  • to ensure there's no degradation of X.400(1988) service between X.400(1988) originators and destinations, the topology of the MTS must be such that no X.400(1984) MTA acts as a relay between any two X.400(1988) users 🛤️.
  • as the existing R&D X.400(1984) service (formerly COSINE MHS) now comprises a large number of X.400(1988) capable RELAYs, it would be relatively straight forward for the existing COSINE MHS RELAYs to be one of the first communities migrated to X.400(1988) capabilities. this would ensure that X.400(1988) MTAs using the RELAY backbone experience no loss of service 🦋.
  • to be able to operate an X.400(1988) service, a properly operated X.400(1988) infrastructure should be established 🏗️, consisting of X.400(1988) MTAs, X.400(1988) MTAs with downgrading capabilities according to RTR 3, Message Store services, and gateways to RFC 822 based upon RTR 2, plus extended gatewaying functionality for multimedia mail 🎞️.
  • to ensure maximum use of the OSI supporting layers plus support of normal mode RTS, it's recommended that a migration to ISO 10021 is effected, i.e., straight to use of the full OSI stack with normal mode RTS 🧱.
  • to ensure maximum quality of service as impacted by implementation decisions related to the 'General Extension Mechanism', it's recommended that no minimal X.400(1988) MTAs (the ones that relay the syntax but understand none of the semantics of extensions) should be used 🙅‍♀️.
  • it's recommended that all X.400(1988) MTAs should generate reports containing extensions copied from the subject message, and route reports through the DL expansion hierarchy where appropriate 📨.
  • it's recommended that all X.400(1984) UAs are able to generate and display DDAs. this will allow such systems to address X.400(1988) Common Name Attribute users 🫶.
  • to enhance connectivity to both X.400(1984 and 1988) management domains without degradation of X.400(1988) service, management domain entry points that support both X.400(1984 and 1988) are recommended 🌉.
  • to ensure total connectivity between RFC 822 domains migrating to X.400(1988), it's recommended that a local X.400-to-RFC-822 gateway is made operational, or a reliable service agreement for the external provision of such a gateway is effected, before any migration begins 🛡️.

Migration utilities needed

  • it's considered very helpful if conversion utilities that allow a flawless conversion of an RFC 822 user's existing mail folders to an X.400(1988) product's folder system are implemented 🗂️. however, further investigation is needed before recommending that such tools be made a mandatory part of any funded software development 🤔.
  • it's recommended that the ease of configuration of X.400(1988) products is made as automatic as possible. consideration should be given to a) modern user interfaces and b) automatic processing of 'old RFC 822' configuration files into the 'new X.400(1988)' configuration files, i.e., a reuse of the user's previous options and configurations should be the result. if a 'simple' configuration interface is needed, it should be as compatible as possible with the present RFC 822 mailer's, i.e., this concretely means editing of ASCII files 💻🎀.

Issues for further study 🔭

okay so this is the pilot's homework list 📝 the X.400(1988) messaging pilot must make sure each of these issues is either already being looked into by an appropriate body, or, if nobody is, it has to start actions to deal with them properly 💅 they're sorted into three piles: Products, Organisational, and Deployment 🧚

  • Products 🎀
    • any changes needed to X.500 DSAs, DUAs and APIs (e.g., LDAP, etc.) so they can support X.400(1988) messaging ✨
    • the X.400(1988) MTAs, UAs, MSs, and the gateways to RFC 822/MIME and X.400(1984), plus gateways to other messaging systems (e.g., Microsoft Mail, Lotus cc:Mail, etc.) 📬
    • User Interfaces that integrate X.400(1988) UAs and X.500 DUAs with user applications such as Word Processors, etc. 💻
    • E-mail network management software, for both users and administrators 🌸
  • Organisational 💜
    • a trusted network for security (i.e., the distribution of security keys), and whether this trusted network should or can be the same as the PEM trusted network that's currently being deployed 🔐
    • usage of PEM within X.400(1988) 🦋
    • PEM to and from X.400(1988) gatewaying 🌈
    • how to register and publicise object IDs for X.400(1988) 📣
    • the addresses of the PRMD and ADMD registration authorities are well publicised 🍓
    • the creation and modification authority for X.400-to-RFC-822 mapping rules is defined 📜
    • the creation and modification authority for MTA routing rules is defined 🛤️
    • what methods should be used to liaise with other bodies like IETF, ISO, EEMA, EMA, etc. 🤝
    • making sure any Public Domain software needed for the X.400(1988) service is distributed widely, quickly and efficiently 🚀
  • Deployment 🧜
    • which services should start such a migration (i.e., COSINE MHS RELAYs, Universities, other) 🎓
    • the topology of the X.400(1988) MTS 🗺️
    • addressing of users between X.400(1984 and 1988) and RFC 822, e.g., how will X.400(1988) T.61 address components be processed by X.400(1984) and RFC 822 systems 🙈
    • which X.400(1988) body parts MUST be supported by the research community 🔥
    • whether any new APIs, or modified APIs, are needed for X.400(1988) and messaging in general 🛠️
    • the specifications and development of any needed Public Domain software 📝
    • what existing Public Domain software should be modified to accommodate X.400(1988) systems 🧚‍♀️
    • how rapidly to deploy the X.400(1988) service ⏩
    • making sure there is 'little or no loss of service' in any migration from X.400(1984), or RFC 822, to X.400(1988) 🫶
    • considering what Value Added Services, based upon X.400(1988), could be started to encourage uptake of X.400(1988) 💖

Authors' Addresses 🎀

okay now the contact bit! only the two editors' full addresses are listed here 💅

Erik Huizer (Task Force chair)
SURFnet bv
P.O. Box 19035
NL-3501 DA  Utrecht
Europe

Phone: +31 30 310 290
RFC 822: huizer@surfnet.nl
X.400:   S=huizer;O=SURFnet;PRMD=surf;ADMD=400net;C=nl;


James A. (Jim) Romaguera
NetConsult AG
Berner Technopark
Morgenstrasse 129
CH-3018 Bern
Europe

Phone: +41 31 998 4141
RFC 822: romaguera@netconsult.ch
X.400: S=romaguera;O=netconsult;PRMD=SWITCH;ADMD=ARCOM;C=CH;

and if you want to reach the whole Task Force at once, use this per e-mail address 🦋

RFC 822: tf-88@SURFnet.nl
X.400:   S=tf-88;O=SURFnet;PRMD=surf;ADMD=400net;C=nl;
📦 where this page comes from