RFCs in HTML Format

RFC 1616

     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

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

   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
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;

Back to RFC index





Register domain name and transfer | Cheap webhosting service | Domain name registration