diff options
Diffstat (limited to 'doc/rfc/rfc1616.txt')
| -rw-r--r-- | doc/rfc/rfc1616.txt | 2467 |
1 files changed, 2467 insertions, 0 deletions
diff --git a/doc/rfc/rfc1616.txt b/doc/rfc/rfc1616.txt new file mode 100644 index 0000000..ad6eb45 --- /dev/null +++ b/doc/rfc/rfc1616.txt @@ -0,0 +1,2467 @@ + + + + + + +Network Working Group RARE WG-MSG Task Force 88 +Request for Comments: 1616 May 1994 +RARE Technical Report: 10 +Category: Informational + + + X.400(1988) for the Academic and Research Community in Europe + + A report by the RARE Task Force on X.400(1988) + of the RARE Working Group on Mail & Messaging + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +1. Abstract + + The European research and development community, as represented by + the member research networks of RARE, has lead the deployment within + the global R&D community of X.400 electronic messaging services, as + specified in the international recommendations CCITT X.400(1984), for + more than five years. As a result of providing such services to the + European R&D users it has become clear that there is an existing and + ever increasing demand from these users for new and enhanced + electronic messaging services and product to be used to communicate + within the R&D community but within commercial service providers and + organisations as well. + + It is also clear that new services, such as Multimedia messaging and + Secure messaging, and the resulting products promise dramatic + benefits and opportunities, for not only the R&D community but also + for the wider commercial, industrial and public communities, in terms + of facilitating innovative ways of working and living which can only + enhance the missions and goals of the respective communities. Not + least the establishment of globally pervasive messaging services + between all users, R&D and commercial, is facilitated by the early + adoption of such advanced new services. An indication of the + importance of such a messaging service can be appreciated if one + considers that in many organizations (especially commercially based) + messaging may be the only method to communicate between independent + organizations due to security considerations and lower layer network + differences. + + The Commission of European Communities (CEC) VALUE subprogram II has + been established to support initiatives relating to the development + and adaptation of R&D networks in member states. Amongst other + + + +RARE WG-MSG Task Force 88 [Page 1] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + initiatives the VALUE program supports X.400 initiatives in certain + countries. VALUE support has so far been limited to X.400(1984) + initiatives, as X.400(1984) has up until now been the dominating OSI + services. However as X.400(1988) implementations have started to + appear a VALUE funded study of the X.400(1988) aspects of messaging + and their impact on the R&D community was felt 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 of the RARE Mails and Messaging Work Group during the + period from November 1992 until October 1993. Open reviews of the + report have occurred in the RARE Mail and Messaging Work Group and + within the IETF X.400ops Working Group. + + The scope of the report is limited to deployment of X.400(1988) + services, and as such the report does not contain any recommendations + on development and deployment of Internet RFC 822 / MIME/ PEM related + (pilot) services. However, 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 + considered. Note: RFC 822 is also known as Internet STD 11. + + Circulation of this report is unlimited. Comments on this report may + 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. + + + + + + +RARE WG-MSG Task Force 88 [Page 2] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + +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 + + This document reports the results of study of the X.400(1988) aspects + of messaging and their impact on the R&D community. The study was + funded by the CEC under VALUE Subprogram II and has been carried out + by a task force on the RARE Mail Working Group. The document is + targeted at technical decision makers as well as those who would fund + activity in this area. + + The document presents the existing situation as regards the + predominate messaging technologies within Europe. These are presented + within the context of a number of large messaging communities that + are using these technologies: + + - RFC 822, + - X.400(1984), + - Mail-11 and + - PC LAN messaging + + + +RARE WG-MSG Task Force 88 [Page 3] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + Three major European communities are referenced: + + - Commercial service providers + - R&D community + - Commercial organisations using messaging services. + + The report states the following facts: + + - The resources, human or financial, to operate multiple wide + area messaging services connecting together independent + organisations are high. As such it is desirable to try and + keep to a minimum the number of such services. This statement + is true for the R&D community but is also highly likely to be + valid for the general European industry. + + - There are two publicly available technological standards + that can be used by open communities, such as the R&D + community and public service providers: the X.400(1984 and + 1988) recommendations and the Internet RFC 822 / MIME / PEM + standards. + + - There is an established very large global user base of + Internet RFC 822 and X.400(1984) messaging services. Both + services have their own momentum within different parts of + the user community, both are still developing and growing + fast. + + The report concludes that X.400(1988) will be the preferred protocol + for inter organizational connection for European industry and + government and parts of the European R&D community. RFC 822 / MIME / + PEM will be the preferred protocol suite for inter-organisational + connection for the Internet community and, as products are already + widely available, it is the preferred protocol for parts of the + European R&D community. + + The goal of European pervasive messaging - incorporating Industry, + Government and Academia - would be best accommodated and reached by + the establishment of a single messaging service. However taking the + above into account, this is not feasible, as X.400(84 and 88) and RFC + 822( and MIME) based services will be around for a long time to come. + To increase the functionality of Wide Area E-mail services there is a + clear necessity to: + + - migrate RFC 822 services to a RFC 822 / MIME / PEM service. + A MIME based service offers more functionality to the user + than a plain RFC 822 service. + + - migrate existing X.400 services to a X.400(1988) service. + + + +RARE WG-MSG Task Force 88 [Page 4] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + Due to the lack of scalability of the X.400(1984) service in + terms of extra functionality, it will become increasingly + difficult 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 it is essential + to have a transparent gateway between the X.400(1988) service + and the RFC 822 / MIME / PEM service, thus ensuring + connectivity between these two services with a maximum + functionality. + + Such a gateway is technically feasible and it is an essential part of + an unified E-mail service. Without such a standardised gateway the + overall E-mail service would deteriorate. + + The lack of open standards for the PC LAN messaging systems + discourages their use as 'backbone' messaging technologies within + open communities. However the products that these systems deliver to + end users ensures that their already large share of the messaging + market will continue to exist for some time. Thus it is also + essential that strategies that allow these systems to be 'seamlessly' + integrated within the global messaging community are put in place. + Not least due to the indications that 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 concludes with a set of recommendations, the main one + being the establishment of a X.400(1988) European pilot messaging + service for the R&D community. This pilot should include the + establishment of a transparent gateway service between X.400(1988) + and RFC 822/MIME. The goal of a European pilot is to ensure the + successful deployment of a European wide operational X.400(1988) + service that is pervasive and meets the needs of users. By collecting + together the issues related to the establishment of a European + X.400(1988) service, this report acts as a focal point and stimulant + for discussion on this topic within the R&D community. In the report + a summary of the benefits and problems of each of the above messaging + technologies within the context of achieving a global messaging + service, of which the R&D community is one part, is presented. + Further the document identifies issues, strategies and + recommendations related to the migration and coexistence of these + technologies within the scope of mainly the European R&D community + but also in relation to other messaging communities. A cost / benefit + analysis on the establishment of a European wide pilot X.400(1988) + messaging service is also presented. Finally a reading list of + references related to this subject has been compiled. + + + +RARE WG-MSG Task Force 88 [Page 5] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + The report does not include any recommendations on development and + deployment of RFC 822 / MIME / PEM related (pilot) services, as these + are outside of the scope of the Task Force. However, 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. + +3. Framework for the report + + With the belief that user demands for new messaging services such as + Multimedia and Secure Messaging would develop, the RARE community + (together with other communities; most notably the Internet + Engineering Task Force (IETF)) has over the preceding years + experimented in new messaging and related technologies. Experiments + and pilots, have been performed in messaging services e.g., as + recommended by CCITT X.400(1988) and Directory Services based upon + the CCITT X.500(1988) recommendations. + + The results of such pilots and experiments indicate that it is now + opportune to commence a pilot X.400(1988) messaging service for the + European R&D community. The major goals of the pilot being, to + + - establish a large scale European wide pilot messaging + service based on X.400(1988). + + - collaborate with and facilitate the commencement of similar + pilot services within diverse communities; both R&D and non- + R&D (e.g., commercial ADMDs and PRMDs, etc.); 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 the user's needs, for instance + X.400(1988) products such as 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. + + - prove that such a service and products efficiently meets the + existing and expected demands for new messaging services by + European R&D users. And as such determine the steps for a + European deployment of an operational X.400(1988) messaging + service. + + - determine the needed steps to facilitate migration for the + existing operational R&D X.400(1984) based messaging service, + as represented by the R&D MHS service (the former COSINE + MHS), RFC 822 / MIME / PEM based messaging services and the + + + +RARE WG-MSG Task Force 88 [Page 6] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + HEPnet / SPAN Mail-11 based messaging service to an + operational X.400(1988) messaging service. It is self evident + that during such 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 needed steps that allow proprietary messaging + systems, that are widely deployed within the European R&D + community to be integrated at as high as possible service + level, by 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 but the report + discusses advantages and disadvantages, costs and enefits and + migration issues for deploying a X.400(1988) service. As such it is a + discussion and feasibility paper on the creation of 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 + + Electronic messaging within Europe can be viewed as a number of + messaging services communities. Three important communities comprise, + + - 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 which have + interconnected using the X.400(1984) protocols. The topology + between these ADMDs, although not yet 'mesh', can be stated + as progressing quite rapidly to this optimum goal. However + there is still a way to go before ADMDs provide full European + connectivity. + + - PRMDs (or private commercial e-mail service providers) have + interconnected to ADMDs and other PRMDs predominantly using + the X.400(1984) protocols but also with proprietary + protocols. + + + + + +RARE WG-MSG Task Force 88 [Page 7] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + Research networks are providing messaging services in every European + country. These R&D service providers are operated as either ADMDs or + PRMDs and are using both X.400(1984) protocols and Internet RFC 822 + protocols to connect to each other. + + Moreover, there are also large 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. In general, all these services are totally interconnected. + As such it is a statement of fact that there exists within the + European R&D community, two parallel interconnected messaging + infrastructures based upon X.400(1984) and RFC 822. However + interconnections between the R&D messaging community and the majority + of the European commercial service providers use the X.400(1984) + protocols. + + It is also clear that the commercial world mostly makes inter- + organizational messaging interconnections using the X.400(1984) + protocols. And also that the commercial messaging world is not as + totally interconnected as the R&D messaging community. Finally, for + a number of commercial and public organisations there is often 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 within both communities do not use X.400(1984) or + RFC 822 messaging systems but systems based upon proprietary + protocols. The 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 connect to + commercial service providers also via proprietary protocols. The PC + LAN messaging services, although probably comprising the largest + number of users, are in general 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 with + the increased use of messaging, there follows an awareness of extra + requirements for related services. These requirements can be + classified into 'User based Requirements' and 'Service Provider based + Requirements' to either support, or exploit, high quality messaging + services. These requirements are elaborated upon within this chapter. + + + +RARE WG-MSG Task Force 88 [Page 8] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + +4.2.1. User Oriented + + The only thing a user requires is an easy to use, well integrated, + user interface to electronic mail. Usually the user does not care + what protocol is used. However there are certain inherent + requirements to the functionality that can be identified as user + requirements. The main user requirements identified are: + + - Distribution Lists (DLs) + + A widely perceived omission from the X.400(1984) recommendations + was the lack of support of DLs. Distribution lists allow users to + enlist themselves onto electronic mail expander lists + (distribution lists). A message to such a distribution list will + automatically, and without significant delay, be sent on to anyone + whose electronic mail address is on that list. Such a list can be + a public list, that is meant for discussions on a specific + subject, much like a sort of "magazine". However the list 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 for many years been frustrated in their + inability to use their national character sets when communicating + using messaging systems. The problems within e-mail systems that + were causing this character set frustration are at their base the + same problem 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 enormous potential of Multimedia systems and services + (especially within the commercial community as evidenced by the + enormous press publicity and mega-mergers positioning companies to + exploit this technology but also within the government spheres + i.e., the U.S.A. Government's 'Information Superhighway' + initiative) has acted as a spur to make rapid progress in solving + the problems in this area. + + - White pages Directory Service + + A white pages directory service provides a unique but very basic + and important service; a way to store and find information about + people and resources that is analogous to a telephone service's + paper based directory i.e., White Pages. User's E-mail addresses + + + +RARE WG-MSG Task Force 88 [Page 9] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + can be stored for subsequent retrieval by E-mail systems. + + - EDI + + EDI today is not extensively used within the academic environment. + However there is 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. + + The significance of maintaining end to end integrity (especially + security aspects) of the EDI messages mandates that no gateways + should be used between originator and recipient. + + - Support of Security services + + E-mail as it is 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 as being the most + significant service provider requirements: + + - Network Management + + This area is still very new, in terms of offering standardised + protocols, services and products for management. However a minimum + 'goal' is to provide for central management functions that will + allow providers to offer a better quality of service. There is + presently 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 that + need to be worked upon include: QOS, Service Level Agreements + (SLAs), Multiple system queue management, Accounting, Routing Co- + + + +RARE WG-MSG Task Force 88 [Page 10] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + ordination and Message Tracing. + + - Support of MTA routing + + Dynamic routing from MTA to MTA, relieves the necessity to + maintain large routing tables, especially within a large PRMD, or + community of PRMDs (like the R&D MHS community). + + - Address mapping between RFC 822 and X.400 + + The widespread use of X.500 or DNS for mapping, allows a reduction + of manpower for centrally co-ordinating globally consistent + X.400-to-RFC-822 mapping tables and distributes the responsibility + for updating the mapping rules. This should allow mapping rules to + change when needed and to be available immediately. + + - UA capabilities registration + + The use of 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 in terms of speeding the + deployment of new messaging services (e.g., Multimedia Messaging). + +4.3. Messaging capabilities + + Due to the problems of gatewaying within a multi-protocol messaging + environment, the great majority of R&D E-mail users are reduced to + using only InterPersonal Messaging (IPM) services based upon the + exchange of message body parts using CCITT character set IA5 (US + ASCII). + + Within the R&D community recent work to meet user requirements for + non ASCII messaging services - as documented above - has resulted in + enhancements to the messaging services based upon RFC 822 protocols. + The enhancements provide Multimedia support via the Multipurpose + Internet Mail Extensions (MIME) and the prospect in the very near + future of secure messaging via Privacy Enhanced Mail (PEM). + Deployment of the MIME enhanced RFC 822 based services, via + distribution of software and the setting up of the needed + organisational structures, has commenced. The PEM enhancements are in + a large scale pilot phase e.g., VALUE PASSWORD project. + + In the case of X.400(1984) the usage of non ASCII body parts is + mostly effected by bilateral agreement between recipient and + originator, through use of body part 14. In practice this restricts + the exchange of non ASCII body parts to those cases where the + recipient and the originator use the same bilateral agreement or else + the originator includes an ASCII message explaining the included + + + +RARE WG-MSG Task Force 88 [Page 11] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + content type. Besides IPM there is a growing usage of EDI on top of + X.400(1984). + + With the above X.400(1984) deficiencies in mind, X.400(1988) has been + specified by the CCITT / ISO to meet new user demands. X.400(1988) + provides support for various different body parts, enhanced security + features, international character set support capabilities and + support of X.500 Directory Services. Due to the technological + potential of these standards to satisfy user needs for new messaging + services, the R&D community has been experimenting and piloting + X.400(1988) and X.500(1988) services. As there is a strong + dependency of X.400(1988) messaging upon X.500(1988) directory + services, the necessary precondition to supply these user demands is + a deployed and operational X.500(1988) directory service. Piloting + and deployment of the X.500(1988) directory service within the R&D + community has been successfully initiated and co-ordinated by the + COSINE and the VALUE PARADISE projects. + + Similarly, secure messaging has been addressed by the VALUE PASSWORD + project and the RARE and IETF communities. Work to solve problems + related to directory support of X.400(1988) messaging has been + pursued 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 not least it should not be + overlooked that X.400(1988), as compared to X.400(1984), provides a + comprehensive basis for gatewaying to and from RFC 822 / MIME / PEM + and PC LAN messaging services. To that respect the IETF has defined + standards for gatewaying Multimedia mail between RFC 822 / MIME / PEM + and X.400(1988). As RFC 822 / MIME / PEM is now being deployed on the + Internet, deployment of X.400(1988) services is needed to assure + multimedia and secure messaging connectivity for the European R&D + community. + +5. Possible solutions for providing globally pervasive messaging + + As can be now seen, a correlation of the present situation to the + requirements of the user, shows that the current messaging services + do not match the needs of users. To try to meet these needs a number + of developments within various messaging technology areas are + occurring. The following messaging technological areas, due to the + present installed user base within the R&D community, 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 + + + +RARE WG-MSG Task Force 88 [Page 12] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + + Ongoing developments within each of the above technological areas + provide new messaging options for the R&D community. The ability of + each technological area to provide solutions for user and service + provider requirements is summarised within this chapter. + +5.1. PC LAN E-mail systems + + Currently the usage of PC LAN E-mail systems is mostly for internal + communication within an organisation. External connections, if + present at all, to public service providers or other organisations is + mostly through gateways to X.400(1984) or RFC 822. The use of a PC + LAN E-mail system in terms of an infrastructure for interconnecting + E-mail systems of different hues is not common within the Research + community. Recent experience, from amongst 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. (The use of native X.400 protocols for PC LAN + E-mail systems would avoid the usage of gateways and would thus + alleviate many of these problems.) A summary of those problems and + some relevant issues follows: + + - 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 under active development, + for connecting together PC LAN messaging systems 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 is one of the benefits that + 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 in the users + 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 + + + +RARE WG-MSG Task Force 88 [Page 13] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + 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 independent 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 will provide the stimulant to various software + developers to develop more portable applications plus allow the + rich functionality of X.400(1988) to be accessed by these + applications thus reducing the need for gatewaying to X.400(1988). + + - Security + + As the 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 is not specific to PC LAN E-mail + systems. + + - Directory Services + + To date mostly proprietary directory services have been deployed + that do not match the needs of the users in terms of access + controls for data, distributed and decentralised across + organisations. X.500 based services promise solutions to such + needs. As a result 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' services requires either, + + - directory information exchange products (i.e., directory + gateways) deployed between a proprietary system and an X.500 + directory system + + + + + + +RARE WG-MSG Task Force 88 [Page 14] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + - 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 should be stressed that gatewaying mechanisms and products are + often problematic due to 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 + + RFC 822 messaging services are widely deployed within the R&D + community. There is ongoing work to extend RFC 822 to meet user + requirements. Some of these extensions are elaborated upon within + this chapter. + + - Distribution lists + + RFC 822 allows for the usage of DLs. Management of DLs is not + (yet) standardised. + + - RFC 822 multimedia messaging via MIME + + With the arrival of MIME, the RFC 822 service has an additional + protocol standard that addresses Multimedia messaging very + comprehensively. In terms of user needs, MIME now allows messaging + body parts to comprise multinational character sets and binary + data. Multi-body part messages are also supported. One of MIME's + real strengths, in terms of deployment within the existing RFC 822 + service, is that it achieves its goals by overlaying its services + over the existing RFC 822 service and thus mandating no changes to + the in place RFC 822 infrastructure. This greatly simplifies the + MIME deployment. + + - RFC 822 secure messaging via PEM + + Just as MIME has brought multimedia messaging to RFC 822 services, + Privacy Enhanced Mail (PEM) is bringing secure messaging to RFC + 822 services. PEM also has used the same approach as MIME to + deploy secure messaging within RFC 822 services; overlay PEM + services over the existing RFC 822 services without requiring + changes to the RFC 822 infrastructure. PEM brings confidentiality + + + +RARE WG-MSG Task Force 88 [Page 15] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + and integrity of messages to RFC 822 users. However a number of + problems with PEM, and X.400(1988) as well, still need to be + solved before secure messaging can be considered to be an + operational service. These problems are independent of the secure + messaging protocol (i.e., PEM or X.400(1988)) and deal mainly with + distribution of secret keys to the end users. There is very active + work going on within the IETF to solve these problems. + + - MIME and PEM + + There are still problems for messages that are simultaneously a + multimedia message, as per MIME, and a secure message, as per PEM. + A PEM encoded MIME message does not allow gatewaying to other + messaging environments and therefore does not allow any of the + features inherent within MIME to be exploited along the message + path. A MIME message that contains PEM encoded body parts can be + gatewayed but the integrity of the entire message is then not + guaranteed. This is a real deficiency of both existing approaches + as it is essential that users are able to simultaneously use + multimedia and secure messaging. However, once again, the IETF is + working very hard on solving these problems and solutions can be + expected, although the solution of the gatewaying of PEM messages + to other E-mail systems is still unclear. + + - Dynamic and distributed messaging routing via the Domain Name + System (DNS) + + RFC 822 messaging benefits greatly by having a dynamic and + distributed mechanism to assist in message routing i.e., Domain + Name System (DNS). With the support of the DNS, RFC 822 MTAs are + able to directly route to other RFC 822 MTAs and thus deliver + messages with a minimum of delay. In practice mail often still + traverses multiple RFC 822 MTAs for a number of reasons e.g., Mail + Hubs provided for users who turn their machine off when they go + home, Firewall Hubs for security reasons, etc. However it is + commonly accepted that between RFC 822 mail hubs the delivery of + messages is very fast. Typically resolution of routing decisions + occurs in less than one minute and very often within seconds. In + general the DNS service is a very valuable service that functions + 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 usage of + multiple character sets in names, subject etc. in RFC 822 headers + [9]. This allows (European) users to use their preferred character + set to support their language not only in the contents of a + + + +RARE WG-MSG Task Force 88 [Page 16] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + message but also in the headers. + + - MIME capable gateways + + It is clear that to provide a seamless service to all users + regardless of whether they are using RFC 822 or X.400 services, 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 such 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 number of proposed Internet + standards to solve these problems, for both X.400(1984) and + X.400(1988) and generated within the MIMEMHS work group of the + IETF, have been completed [4]. + + - Access to fax, teletex, telex or physical delivery + + For the moment, there is no standardised way for RFC 822 users to + access gateways to the above services except by indirect access to + X.400(1988) systems (i.e., concatenated gateways of RFC 822 to + X.400(1988) and then onwards to the appropriate X.400(1988) Access + Unit). Although even this indirect method would require some + further work on standardising mappings between RFC 822 addresses + and X.400(1992)'s X.121 addresses. As well some experiments within + the RFC 822 world are occurring on routing fax messages. + + - Operational support + + Generally, RFC 822 messaging services are delivered on a 'best + effort' basis and thus service level agreements requesting + stringent response times to operational problems or guaranteed + delivery times for messages are difficult to agree. This phenomena + 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 makes it hard to reach a 'one stop + shopping' agreement for RFC 822 messaging services. + + - Notifications + + The RFC 822 service provides a minimum amount of base protocol + support for messaging users. It could be argued that the RFC 822 + protocol is simplified by this choice and thus software that + implements the standard need be smaller in size and easier to + build. However some features e.g., delivery & receipt + notifications and UA capabilities registration, would be commonly + accepted as being desirable from a user standpoint and thus + + + +RARE WG-MSG Task Force 88 [Page 17] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + desirable extensions to RFC 822. Some operational problems + relating to reliability could be minimised by technology that has + a standardised support for positive and negative notifications of + messages. RFC 822, as compared to X.400, technology does not yet + support positive notifications (although there is work starting + within the IETF to extend RFC 822 to support delivery + notifications). However within 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 to address the lack of adequate + service quality - 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 being the 'bin/mail' format and the other 'MH' + format. This 'standard' mailbox format is a definite benefit for + RFC 822 users as it allows them to change RFC 822 UAs (e.g., + upgrading to MIME RFC 822 UAs) whilst not 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. As a result, users are spared the effort of + installing RFC 822 MTA software. If for some reason, a user or + mail administrator should wish to install a different MTA or UA to + the pre-installed system, there exists a large number of easily + available (i.e., via widespread distribution amongst many FTP and + other information servers) public domain RFC 822 MTAs and UAs. + + Both of the above points encourages the spread and eases the + installation of software for the RFC 822 messaging service and in + many ways explains the size and importance of the installed base + of RFC 822 systems. To illustrate the extent of RFC 822 / MIME + products, a non-comprehensive list of available MIME enhanced RFC + 822 products follows; 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. + + - 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. + + + +RARE WG-MSG Task Force 88 [Page 18] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + +5.3. X.400 - 1984 and 1988 + + X.400(1988) substantially upgrades and enhances the X.400(1984) + standards. A number of new functions have been incorporated within + X.400(1988). A description of the most important features of X.400 - + 1984 and 1988 - follows. + + - Notifications + + X.400(1984) provides four notifications - positive and negative + delivery notifications and positive and negative receipt + notifications. These notifications allow users to ensure + successful message delivery or that the message was read. The + delivery notifications are also used by service operators in their + fault escalation procedures. + + - Binary Data Transfer + + X.400(1984) allows binary data transfer to be transported without + the necessity of character encoding. The ability to transfer files + of whatever type is a valuable end user service. As well the lack + of any necessary character encoding allows users to utilise the + received data without needing any character decoding software. + + - Multiple Body Parts + + The ability to send multiple body parts within one message gives + the user the ability to send multiple logical components within + one message. This is a natural mechanism for users as it mirrors + the real life situation of being able to send within one message, + a letter, a word processor file, a spreadsheet file, etc. + + - Feature rich messaging model + + The features of X.400 are very rich. This provides benefits for + users as vendors are able to provide applications that can utilise + these extensive features in an interoperable manner due to the + standardisation of the features within X.400. + + - Clear messaging model + + X.400(1984), as one of its most wide reaching achievements, has + popularised within the market a consistent and clear model to + describe message handling systems. The decomposition of a message + handling system 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. + + + +RARE WG-MSG Task Force 88 [Page 19] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + - Multiple lower layer networks + + X.400 has embraced the concept that there are different technology + lower layer networks. This concept even allows multiple logical + networks of the same technology to be supported. X.400 allows the + messaging service to 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. + + The list of major X.400(1988) extensions to X.400(1984) follows: + + - 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 a 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 provision of + powerful nesting capabilities plus management mechanisms for DL + owners within X.400(1988) DLs are features providing attractive + benefits for 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, solving + the problems of non-continuous availability of such UAs. The + message store allows mobile workers, small offices and local + schools to become active messaging users in a cost effective + manner. The message store provides powerful selection mechanisms + allowing the user to select messages to be transferred between the + store and the workstation. This facility is not catered for + adequately by the P3 protocol of X.400(1984) and provides a major + incentive for transition. + + + + + +RARE WG-MSG Task Force 88 [Page 20] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + - X.500 Directory names + + Support for use of 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 the O/R addresses is a powerful feature for users as it + frees them of the necessity to insert O/R addresses containing + routing information but allows them to insert the more natural + directory names. However, the management of 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 provide native + X.400(1988) services to users and applications thus 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 need + still to be solved. Organisational issues of globally scaling the + distribution of secret keys is 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 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) + + + +RARE WG-MSG Task Force 88 [Page 21] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + 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, there is a + further text exchange standard such as ODIF, Hytime, etc., needed. + + - Character set support for extended addressing + + A highly desirable potential benefit for European R&D users is + provided by 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 has + 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 + provides 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. + + + + + + +RARE WG-MSG Task Force 88 [Page 22] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + - 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 allow 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) + + What is clear from the previous chapters is that; + + - The resources, human or financial, to operate multiple wide + area messaging services connecting together independent + organisations are high. As such it is desirable to try and + keep to a minimum the number of such services. This statement + is true for the R&D community but is also highly likely to be + valid for the general European industry. + + - There are two publicly available technological standards + that can be used by open communities, such as the R&D + community and public service providers: the X.400(1984 and + 1988) recommendations and the Internet RFC 822 / MIME / PEM + standards. + + - There is an established very large global user base of + Internet RFC 822 and X.400(1984) messaging services. Both + services have their own momentum within different parts of + the user community, both are still developing and growing + fast. + + From the above discussion, it is clear that the infrastructure + services that have to be supported within these open communities, and + especially within 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 inter-organisational connection for European industry + and government and parts of the European R&D community. RFC 822 / + + + +RARE WG-MSG Task Force 88 [Page 23] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + MIME / PEM will be the preferred protocol suite for inter- + organisational connection for the Internet community and, as products + are already widely available, it is the preferred protocol for parts + of the European R&D community. + + The goal of European pervasive messaging - incorporating Industry, + Government and Academia - would be best accommodated and reached by + the establishment of a single messaging service. However taking the + above into account, this is not feasible, as X.400 and RFC 822 based + services will be around for a long time to come. To increase the + functionality of Wide Area E-mail services there is a clear necessity + to: + + - migrate RFC 822 services to a RFC 822 / MIME / PEM service. + A MIME based service offers more functionality to the user + than a plain RFC 822 service. + + - migrate existing X.400 services to a X.400(1988) service. + Due to the lack of scalability of the X.400(1984) service in + terms of extra functionality, it will become increasingly + difficult 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 it is essential + to have a transparent gateway between the X.400(1988) service + and the RFC 822 / MIME / PEM service, thus ensuring + connectivity between these two services with a maximum + functionality. + + Such a gateway is technically feasible and it is an essential part of + an unified E-mail service. Without such a standardised gateway the + overall E-mail service would deteriorate. + + The lack of open standards for the PC LAN messaging systems + discourages their use as 'backbone' messaging technologies within + open communities. However the products that these systems deliver to + end users ensures that their already large share of the messaging + market will continue to exist for some time. Thus it is also + essential that strategies that allow these systems to be 'seamlessly' + integrated within the global messaging community are put in place. + Not least due to the indications that the main messaging vendors are + 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. + + + + + +RARE WG-MSG Task Force 88 [Page 24] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + To make migration to a X.400(1988) service feasible, extensive + migration and coexistence options for various non-X.400(1988) users + have to be developed. Main issue in each migration strategy remains + the co-operation of the users. The migration needs to be user-driven, + i.e., the users need to be convinced of the added functionality + (versus the cost) of migrating towards X.400(1988). A detailed + summary of the different issues and possible problems involved in the + transition to a X.400(1988) based messaging service, with respect to + what are commonly accepted as the four most important messaging + services: RFC 822, MIME and PEM; X.400(1984); MAIL-11 and PC LAN + messaging systems are presented in this chapter. + +6.1. PC LAN E-mail systems + + To provide coexistence and migration the usage of gateways is + unavoidable. The quality of these gateways, with regard to: + + - Transparency (gatewaying multimedia messages, transparent + addressing) + - Manageability + - Reliability + + has to be improved. Ultimately through usage of APIs like MAPI and + CMC, the users interface hopefully will become independent of the + mail protocol that is used. It will then be expected to be possible + to let the user retain his preferred mail user interface, while the + protocol used migrates to X.400(1988). + + Via the use of these APIs it may be possible to access the full + features of X.400(1988) while retaining a proprietary PC LAN UAs. + This way a PC LAN can be easily connected to a X.400(1988) backbone. + This usage of APIs to ease migration for end users should be + encouraged. + + The migration of PC LAN E-mail systems will likely be driven by the + commercial vendors of mail enabled applications, such as UAs, Work + Group Systems, Task Flow Systems plus X.400(1988) MTAs and gateways + able to serve these applications via these 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 formulated for those management domains that wish to effect + this change. As well a long term transition and coexistence phase + needs to be accommodated due to the existing base of RFC 822 users. + An understanding of the issues involved in migrating from RFC 822 to + X.400(1988) messaging services is essential before any rational + decisions on migration can occur. Certainly one, if not the main, + + + +RARE WG-MSG Task Force 88 [Page 25] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + issue in such a migration is that the migration must allow a + transition period where maximum functionality between both services + exists. Any migration must be aware that RFC 822 messaging services + are a 'moving target'. + + - Ease of transition as perceived by an RFC 822 user mandates + that the user's existing mail folders are converted into the + new mail product's folder system flawlessly. + + - The RFC 822's user's e-mail address should remain the same + even after a migration. (i.e., the user keeps the same address + that has two different notation forms: X.400 and RFC 822). + + - Users contemplating a migration will be stimulated to do so + if they experience no loss of service as regards MIME and + X.400(1988) gatewaying; are still able to insert RFC 822 + style addresses into the X.400(1988) UA and are provided with + high performance X.400-to-RFC 822 gateways. + + - The added connectivity provided by X.400(1984 or 1988) + gateways to fax, telex, post etc. plus additional X.400 users + that the user is able to reach easily (whilst not losing + connectivity to RFC 822 addresses) plus the additional + functionality of X.400(1988) possible when communicating with + X.400(1988) users will also act as a stimulant to a + migration. + + - The functionality provided by RFC 822 / MIME products will + be the yardstick that an RFC 822 user compares an offered + X.400(1988) product with. As such 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 within the seconds + time scales and ease of configuration of products. At present + there is no RFC 822 equivalent to X.400 delivery and receipt + notifications and as such these functions are seen as extra + functionality by the user. + + - A follow on to the extra functionality point above is that + present RFC 822 users, most likely commercial users, that + want to be able 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). A decision to + use X.400(1988) in this case would be especially attractive + for those commercial RFC 822 users that are already operating + multiple lower layer networks. As X.400(1988) accommodates + multiple different network layers easily, the cost to migrate + could be considered quite small. + + + +RARE WG-MSG Task Force 88 [Page 26] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + +6.3. X.400(1984) services + + A number of problems can be identified in a migration from + X.400(1984) to X.400(1988). They are summarised as, + + - OSI supporting layers are mandatory in the ISO10021 MOTIS + standard, while the support of the complete OSI stack (normal + mode ) is optional in the otherwise equivalent CCITT + X.400(1988) specifications. It is thus recommended that the + migration from X.400(1984) should be straight to ISO 10021 + i.e., straight to use of the full OSI stack with normal mode + RTS. + + - There is 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, which relay the syntax but understand none + of the semantics of extensions, should be used. + + - All X.400(1988) MTAs should generate reports containing the + extensions that are present in the original message and route + such reports through the DL expansion hierarchy where + appropriate. + + - Choice of standards to be used within mixed X.400(1984 and + 1988) management domains needs to accommodate in one option + the danger of undetectable routing loops from incorrectly + configured routing entries and in another option the problem + that systems that have fixed the routing loop problem may not + all be consistently implemented due to ambiguities within the + standards. 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 to address + X.400(1988) Common Name Attribute users [2]. + + - Minimum loss of service quality mandates that downgrading of + X.400(1988) body parts to X.400(1984) bodyparts be done + according to the MIMEMHS specifications [4]. + + - 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. + + + + + + +RARE WG-MSG Task Force 88 [Page 27] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + - Ensuring 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 the last point is that the existing European + Research X.400(1984) - formerly COSINE MHS - MTA RELAY backbone + should be one of the first MTA communities to migrate to X.400(1988). + +6.4. Mail-11 services + + The Mail-11 (also known as DECnet mail) e-mail service is the major + e-mail service used within the High Energy Physics and Space Physics + Analysis Networks (i.e., HEPnet and SPAN) and is the native e-mail + service present on VMS operating systems. The Mail-11 service is + considered the most popular service by the large HEPnet / SPAN + community. Mail-11 provides also large and 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. + + Jointly with the "old style" Mail-11 UA, the DECnet Phase V (OSI + CLNS) service provides the native capability to run X.400 (88) and + X.400(1984) services. There is thus the potential for X.400 (88) + services to become available as soon as the HEPnet / SPAN community + migrates to DECnet Phase V. However the availability of VMS based UAs + for the X.400(1988) service is still very limited and is thus forcing + users to continue to stay with their Mail-11 UA (and thus the Mail-11 + service). + + Users in HEPnet / SPAN are demanding enhancements to their mail + services to support multimedia and delivery / read receipt services. + This is a strong driving factor for good X.400(1988) UAs to become + available soon to allow users to properly use the available + X.400(1988) service of DECnet Phase V. + +7. Benefits of migrating to X.400(1988) and the involved costs + + The actual as compared to the potential benefits of migrating from + one's existing mail system to a new mail protocol is very dependent + on good products, good organisation of the migration and a degree of + commitment that the transition is worth the cost. Quantifiable and + accurate cost / benefit ratios for such a migration are not possible + within the decentralised European R&D environment and as such are not + generated. + + We have in this chapter listed the benefits that such a migration to + X.400(1988) achieves. We have also given an indication of the + relative costs of such a migration. Provided that there are good + products, and taken in conjunction with the recommendations of + + + +RARE WG-MSG Task Force 88 [Page 28] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + Chapter 8 and Appendices A and B, the task force is confident that + these potential benefits will translate into actual benefits and be + worth the costs incurred. + +*Benefits* + + Below is a list of non-technically oriented benefits and the features + of X.400(1988) that enable these benefits to occur. The benefit of, + + - efficient and innovative communication within Europe is + assisted by establishing an X.400(1988) messaging service + that integrates European industry, government and academia; + + - an increase in business efficiency by the use of EDI (for + example automatic processing of business forms, exchange of + business contracts, etc.) is enhanced by the security aspects + of X.400(1988) i.e., non-repudiation, authentication, + confidentiality, integrity plus secure access between MHS + components. + + - allowing European users to communicate in their native + European languages is brought about by the GeneralText body + part of X.400(1988). + + - remote users and Small and Medium size Enterprises(SME) + using e-mail for electronic commerce is encouraged by + reducing the entry level costs for use of e-mail. An SME's + use of Remote UAs in conjunction with a service provider's MS + -instead of purchasing their own MTA - is accommodated by + X.400(1988). + + - providing global messaging for all e-mail users, but + recognising the existing market realities of heterogeneous e- + mail systems, would be enhanced by the establishment of + gateways to X.400(1988). + + - being able to recover costs by charging and accounting for + messaging services back to users - this is especially + important for commercial service providers - is brought about + by the message auditing capabilities of X.400(1988). + + - communication with users that have no access to E-mail (for + example if such users are defined within Distribution Lists) + is enhanced by X.400(1988)'s support for gateways to physical + delivery, fax, telex, teletex, etc. + + + + + + +RARE WG-MSG Task Force 88 [Page 29] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + - building upon the existing X.400(1984) infrastructure (i.e., + reduction of establishment costs) is brought about by + migrating the X.400(1984) infrastructure to X.400(1988). + + - a reduction in manpower (and thus costs) to manage a global + messaging service is brought about by the messaging service's + ability to utilise the global distributed directory for + management information. + + - the messaging infrastructure to meet new user requirements + is enhanced by the support for General Extensible Mechanism. + + - making E-mail more user friendly is brought about by a + messaging service that allows the use of the more natural + directory names in E-mail addresses. + + - increased effectiveness of messaging by the use of DLs is + brought about by X.400(1988)'s support of powerful nesting + capabilities and management for DLs. + + - an increase in global message delivery performance and + reliability is enhanced by the ability of X.400(1988) to use + X.500 for MTA routing. + + - more messages being successfully 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 such as + audio and video. + + - establishing optimum and seamless conversion of messages + based upon the capabilities of a user is brought about by 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 and + - a cost per user MTA for migrating to X.400(1988). + + + + +RARE WG-MSG Task Force 88 [Page 30] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + To bring about the benefits, mentioned above, certain costs will be + incurred and they are 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 a MHS Co-ordination service in place that could be used + for this function and the number of backbone RELAY MTAs is less + than 100 in number 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 for migrating the infrastructure + towards X.400(1988) is relatively low. + + - The operational costs for organisational issues, for + example dealing with OID registrations, is 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 + + + +RARE WG-MSG Task Force 88 [Page 31] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + 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 a 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 associated with the migration increase as the migration + evolves towards the end users. + + The benefits of migrating to a 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 + + + +RARE WG-MSG Task Force 88 [Page 32] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + 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 is important to realise that if end users themselves do not + experience direct feedback of the benefits from X.400(1988), this may + make the organisational motivation needed to effect such a 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 and thus achieving end user benefits - as listed above - + must be given a higher priority within a X.400(1988) service than + solely the extra service provider benefits. + +8. Main Recommendations + + The RARE WG-MSG Task Force on 'The Establishment of an X.400(1988) + Pan European Pilot Messaging Service' has identified a number of high + level recommendations for establishing such a + service. The main high level recommendations are listed within this + chapter. A more detailed elaboration of these main recommendations is + given in Appendix A. Appendix A is provided for policy makers wishing + more background on the main recommendations. As well, a list of very + detailed guidelines, plus some issues requiring further + investigation, is given in Appendix B. Appendix B will be especially + useful for personnel seeking detailed technical guidelines which are + consistent with the main high level recommendations. + +*Recommendations* + + - Establish a X.400(1988) pilot service encompassing European + Commercial, Government and Academic bodies. Such a pilot + service to be co-ordinated by using an industry forum where + all parties could meet. The use of an existing forum, where + user organisations are well represented, is desirable if + commercial end users organisation's requirements are to be + met. The forum should also be open to non-European + participants. + + - X.400(1988) end user services should be provided as well as + a X.400(1988) backbone RELAY MTA service within a X.400(1988) + pilot service. The end user services should be given a high + priority. + + - Help an already emerging market place in X.400(1988) + products to prosper by ensuring that a suitable supply of + high quality X.400(1988) public domain software is available. + + + +RARE WG-MSG Task Force 88 [Page 33] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + The Internet has proven, that public domain software, free of + any commercial restrictions, is further rapidly developed, by + Small and Medium Size Enterprises (SMEs), into derivative + products suitable for the commercial market. + + - Any pilot service should be well co-ordinated and result + driven but utilise a distributed market oriented approach. It + is considered very difficult to organise and plan such a + pilot under the assumption of a single centrally funded body + i.e., driven from the 'top'. 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 ever more 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 will provide a 'bootstrap' + path for academic organisations to internationally pilot + X.400(1988) services. Such 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, as these + are outside of 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 + + Security issues are not discussed in this memo. + + + + + + + + + + + + +RARE WG-MSG Task Force 88 [Page 34] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + +10. Reading List and Bibliography + + This section contains a list of relevant reference documents that can + be used for further reading. + + [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. + + + + + + + +RARE WG-MSG Task Force 88 [Page 35] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + [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. + + + + + + + + + + + + + +RARE WG-MSG Task Force 88 [Page 36] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + +11. Terminology + + 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 + + + + +RARE WG-MSG Task Force 88 [Page 37] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + +Appendix A - Elaboration on the main recommendations + + The main recommendations of the report are elaborated upon in more + detail within this appendix. + + - In order to provide a globally pervasive messaging service, + it is recommended to establish a well operated Pan-European + X.400(1988) pilot backbone comprising MTAs and MSs, + connecting partners within Industry, Commercial Service + Providers, Academia and Public Bodies (CEC, National + Governments, etc.). The pilot should be open to global + participation. + + - In order to maintain the widest connectivity with the + highest possible functionality, gateways should be installed + that gateway between X.400(1988) and RFC 822/MIME. These + gateways should follow the specifications of RFC 1327 [1] and + RFC 1494 et al. [4]. Experience with these gateways should be + fed back into the appropriate RARE and IETF Working Groups to + improve the standards. + + - In order that the 'business needs' of non-R&D organisations + can be inserted at an early stage into the goals of the pilot + and ensuring that the success of the pilot in meeting these + goals can be measured and disseminated i.e., to encourage the + active participation of non-R&D organisations within the + pilot, it is 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. + + - In order for meaningful co-operation between bodies affected + by the pilot to occur and thus hopefully reducing unnecessary + duplications, it is 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 mechanism for a meaningful + liaison is that enough participants of the above + organisations attend the common forum mentioned above. It is + also suggested that as much as possible e-mail distribution + lists be used to communicate between forum participants. + + - In order that the pilot have measurable results, it is + recommended that the pilot shall be implemented in phases. It + is considered that at least two phases are needed: + + + + + +RARE WG-MSG Task Force 88 [Page 38] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + - 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 is expected + that upon successful completion of this phase a natural + evolution to a global deployment of a X.400(1988) + service will have started. + + - In order to rapidly complete phase 1 of the pilot and that + the pilot is at least Pan-European in scope, it is + 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. + + - In order to stimulate the creation of an economically viable + market place for X.400(1988) products (i.e., MTAs, UAs, etc.) + (i.e., users are willing to purchase such products), it is + recommended that a suitable minimum number of new software + implementations and or modifications to existing software + implementations be funded. The resulting software to be + inserted into the Public Domain free of any financial + restrictions on further commercial exploitation. By using + this mechanism, Small and Medium Size Enterprises (SMEs) will + be encouraged to commercially exploit such products. + + - Due to the strong influence of the R&D community within the + pilot plus the desire to produce standardised products + quickly and pragmatically, it is 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]. + + + + +RARE WG-MSG Task Force 88 [Page 39] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + - To ensure that there is a market driven demand for + X.400(1988) products within the commercial market place, it + is recommended that the maximum number of Public Domain + implementations that are funded, by any one public funding + organisation, is two. It is desirable that at least one other + product, preferably commercially based and not within the + Public Domain, is produced. + + - In order that any necessary information required for the + effective operation of the X.400(1988) pilot, including not + least OID assignments, mapping rules, information about + interconnection partners, naming authority information be + made widely available, it is recommended that an + electronically accessible information base be established. + + - In order that any necessary organisational issues needed for + a deployment of an X.400(1988) service have a body in place + to deal with this issue, it is recommended that the pilot + either identify and list which bodies are responsible for + which issues or else actively ensure that a suitable body is + being put in place. + +Appendix B - A number of detailed guidelines. + + The Task Force has the following detailed guidelines: + +*Product and operational service guidelines* + + - To ensure that there is 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 that the + existing COSINE MHS RELAYs be one of the first communities + that are 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 and + extended gatewaying functionality for multimedia mail. + + + + +RARE WG-MSG Task Force 88 [Page 40] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + - To ensure maximum use of the OSI supporting layers plus + support of normal mode RTS, it is 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 is recommended that no minimal X.400(1988) + MTAs, which relay the syntax but understand none of the + semantics of extensions, should be used. + + - It is 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 is 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 is 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 is considered very helpful if conversion utilities that + allow a flawless conversion of an RFC 822 user's existing + mail folders to a X.400(1988) product's folder system be + implemented. However further investigation is needed before + recommending that such tools be made a mandatory part of any + funded software development. + + - It is 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 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 + + + +RARE WG-MSG Task Force 88 [Page 41] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + 822 mailer's i.e., this concretely means editing of ASCII + files. + +*Issues for further study* + + The pilot X.400(1988) messaging service must ensure that the issues + listed below are either being investigated by an appropriate body or + if not initiate actions to properly address them. The issues have + been grouped under Products, Organisational and Deployment. + + - Products + + - Any X.500 DSAs, DUAs, APIs e.g., LDAP, etc. changes + needed to support X.400(1988) messaging. + + - X.400(1988) MTAs, UAs, MSs, 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 both for users and + administrators + + - Organisational + + - 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 presently + under deployment. + + - 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). + + - addresses are well publicised of PRMD and ADMD + registration authorities. + + - creation and modification authority for X.400-to-RFC- + 822 mapping rules is defined. + + - creation and modification authority for MTA routing + rules is defined. + + + +RARE WG-MSG Task Force 88 [Page 42] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + + + - what methods should be used to liaison to other bodies + like IETF, ISO, EEMA, EMA, etc. + + - ensuring that 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. + + - if 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. + + - ensuring that 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). + + + + + + + + + + +RARE WG-MSG Task Force 88 [Page 43] + +RFC 1616 X.400(88) for European Academics and Research May 1994 + + +Authors' Addresses + + Only the two editors' complete 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; + + The Task Force as a whole can be reached per e-mail at the + address: + + RFC 822: tf-88@SURFnet.nl + X.400: S=tf-88;O=SURFnet;PRMD=surf;ADMD=400net;C=nl; + + + + + + + + + + + + + + + + + + + + +RARE WG-MSG Task Force 88 [Page 44] + |