Movatterモバイル変換

Network Working Group                          RARE WG-MSG Task Force 88Request for Comments: 1616                                      May 1994RARE Technical Report: 10Category: InformationalX.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 & MessagingStatus 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 otherRARE 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 InternetRFC 822 / MIME/ PEM related   (pilot) services. However, since the report shows that both   X.400(1988) andRFC 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 1994Table 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                                                  37Appendix A - Elaboration on the main recommendations             38Appendix B - A number of detailed guidelines.                    40   Authors' Addresses                                               442.  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 messagingRARE 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 InternetRFC 822 / MIME / PEM      standards.    - There is an established very large global user base of      InternetRFC 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) andRFC822( 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:    - migrateRFC 822 services to aRFC 822 / MIME / PEM service.      A MIME based service offers more functionality to the user      than a plainRFC 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) andRFC822/MIME/PEM. For the European R&D community it is essential      to have a transparent gateway between the X.400(1988) service      and theRFC 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) andRFC 822/MIME gateways, a strategy to link   these systems together via X.400 andRFC 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)   andRFC 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 ofRFC 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) andRFC 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 theRARE 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),RFC822 / 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 Messaging4.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 InternetRFC 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) andRFC 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) orRFC 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) orRFC 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 19944.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 addressesRARE 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 betweenRFC 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) andRFC 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 uponRFC 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 enhancedRFC 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 includedRARE 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 fromRFC 822 / MIME / PEM   and PC LAN messaging services. To that respect the IETF has defined   standards for gatewaying Multimedia mail betweenRFC 822 / MIME / PEM   and X.400(1988). AsRFC 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 servicesRARE 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) orRFC 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) (orRFC 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 theRARE 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 (orRFC 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) andRFC 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 systemRARE 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 servicesRFC 822 messaging services are widely deployed within the R&D   community. There is ongoing work to extendRFC 822 to meet user   requirements. Some of these extensions are elaborated upon within   this chapter.   - Distribution listsRFC 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, theRFC 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 existingRFC 822      service, is that it achieves its goals by overlaying its services      over the existingRFC 822 service and thus mandating no changes to      the in placeRFC 822 infrastructure. This greatly simplifies the      MIME deployment.   -RFC 822 secure messaging via PEM      Just as MIME has brought multimedia messaging toRFC 822 services,      Privacy Enhanced Mail (PEM) is bringing secure messaging toRFC822 services. PEM also has used the same approach as MIME to      deploy secure messaging withinRFC 822 services; overlay PEM      services over the existingRFC 822 services without requiring      changes to theRFC 822 infrastructure. PEM brings confidentialityRARE WG-MSG Task Force 88                                      [Page 15]

RFC 1616     X.400(88) for European Academics and Research      May 1994      and integrity of messages toRFC 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 otherRFC 822 MTAs and thus deliver      messages with a minimum of delay. In practice mail often still      traverses multipleRFC 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 betweenRFC 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 forRFC 822 headers was defined that allows for usage of      multiple character sets in names, subject etc. inRFC 822 headers      [9]. This allows (European) users to use their preferred character      set to support their language not only in the contents of aRARE 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 usingRFC 822 or X.400 services, a      widely available set of well run and standardisedRFC 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 forRFC 822 users to      access gateways to the above services except by indirect access to      X.400(1988) systems (i.e., concatenated gateways ofRFC 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 betweenRFC 822 addresses      and X.400(1992)'s X.121 addresses. As well some experiments within      theRFC 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 theRFC 822 MTA's routing mechanism      i.e., DNS. As a result it makes it hard to reach a 'one stop      shopping' agreement forRFC 822 messaging services.   - Notifications      TheRFC 822 service provides a minimum amount of base protocol      support for messaging users. It could be argued that theRFC 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 thusRARE WG-MSG Task Force 88                                      [Page 17]

RFC 1616     X.400(88) for European Academics and Research      May 1994      desirable extensions toRFC 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 extendRFC 822 to support delivery      notifications). However withinRFC 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 ofRFC 822 products      There are only a few mailbox formats in general use byRFC 822      software, one being the 'bin/mail' format and the other 'MH'      format.  This 'standard' mailbox format is a definite benefit forRFC 822 users as it allows them to changeRFC 822 UAs (e.g.,      upgrading to MIMERFC 822 UAs) whilst not compromising or      converting their existing archived mail, which may comprise 1000s      of archived messages.   - System support forRFC 822 products      Normally,RFC 822 MTAs and UAs come pre-installed on UNIX      workstations. As a result, users are spared the effort of      installingRFC 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 domainRFC 822 MTAs and UAs.      Both of the above points encourages the spread and eases the      installation of software for theRFC 822 messaging service and in      many ways explains the size and importance of the installed base      ofRFC 822 systems. To illustrate the extent ofRFC 822 / MIME      products, a non-comprehensive list of available MIME enhancedRFC822 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 andRFC 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 19945.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 InternetRFC 822 / MIME / PEM        standards.      - There is an established very large global user base of        InternetRFC 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, areRFC 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 andRFC 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:      - migrateRFC 822 services to aRFC 822 / MIME / PEM service.        A MIME based service offers more functionality to the user        than a plainRFC 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) andRFC822/MIME/PEM. For the European R&D community it is essential        to have a transparent gateway between the X.400(1988) service        and theRFC 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) andRFC 822/MIME gateways, a strategy to link   these systems together via X.400(1988) andRFC 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 fromRFC 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 ofRFC 822 users.   An understanding of the issues involved in migrating fromRFC 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 thatRFC 822 messaging services   are a 'moving target'.    - Ease of transition as perceived by anRFC 822 user mandates      that the user's existing mail folders are converted into the      new mail product's folder system flawlessly.    - TheRFC 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 andRFC 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 insertRFC 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 toRFC 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 byRFC 822 / MIME products will      be the yardstick that anRFC 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 noRFC 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      presentRFC 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 commercialRFC 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 19946.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 ofRARE 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 overallRARE 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 endRARE 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 inAppendix 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 inAppendix 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      evolvingRFC 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 ofRFC 822 / MIME / PEM related (pilot) services, as these   are outside of the scope of the Task Force. However, since both   X.400(1988) andRFC 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 199410. 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                  andRFC 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 andRFC 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 andRFC 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 199411. 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 toRFC 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 MessagingRARE WG-MSG Task Force 88                                      [Page 37]

RFC 1616     X.400(88) for European Academics and Research      May 1994Appendix 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) andRFC 822/MIME. These      gateways should follow the specifications ofRFC 1327 [1] andRFC 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) andRFC 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 toRFC 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 betweenRFC 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 anRFC 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 'oldRFC 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 RFCRARE 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 toRFC 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) andRFC 822 e.g., how will X.400(1988) T.61 address           components be processed by X.400(1984) andRFC 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), orRFC 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 1994Authors' 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 290RFC 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 4141RFC 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]