doc: Add RFC documents

1 files changed, 2467 insertions, 0 deletions

diff --git a/doc/rfc/rfc1616.txt b/doc/rfc/rfc1616.txt
new file mode 100644
index 0000000..ad6eb45
--- /dev/null
+++ b/doc/rfc/rfc1616.txt
@@ -0,0 +1,2467 @@
+
+
+
+
+
+
+Network Working Group                          RARE WG-MSG Task Force 88
+Request for Comments: 1616                                      May 1994
+RARE Technical Report: 10
+Category: Informational
+
+
+     X.400(1988) for the Academic and Research Community in Europe
+
+            A report by the RARE Task Force on X.400(1988)
+             of the RARE Working Group on Mail & Messaging
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+1.  Abstract
+
+   The European research and development community, as represented by
+   the member research networks of RARE, has lead the deployment within
+   the global R&D community of X.400 electronic messaging services, as
+   specified in the international recommendations CCITT X.400(1984), for
+   more than five years. As a result of providing such services to the
+   European R&D users it has become clear that there is an existing and
+   ever increasing demand from these users for new and enhanced
+   electronic messaging services and product to be used to communicate
+   within the R&D community but within commercial service providers and
+   organisations as well.
+
+   It is also clear that new services, such as Multimedia messaging and
+   Secure messaging, and the resulting products promise dramatic
+   benefits and opportunities, for not only the R&D community but also
+   for the wider commercial, industrial and public communities, in terms
+   of facilitating innovative ways of working and living which can only
+   enhance the missions and goals of the respective communities. Not
+   least the establishment of globally pervasive messaging services
+   between all users, R&D and commercial, is facilitated by the early
+   adoption of such advanced new services. An indication of the
+   importance of such a messaging service can be appreciated if one
+   considers that in many organizations (especially commercially based)
+   messaging may be the only method to communicate between independent
+   organizations due to security considerations and lower layer network
+   differences.
+
+   The Commission of European Communities (CEC) VALUE subprogram II has
+   been established to support initiatives relating to the development
+   and adaptation of R&D networks in member states.  Amongst other
+
+
+
+RARE WG-MSG Task Force 88                                       [Page 1]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+   initiatives the VALUE program supports X.400 initiatives in certain
+   countries. VALUE support has so far been limited to X.400(1984)
+   initiatives, as X.400(1984) has up until now been the dominating OSI
+   services. However as X.400(1988) implementations have started to
+   appear a VALUE funded study of the X.400(1988) aspects of messaging
+   and their impact on the R&D community was felt necessary. This report
+   is one of the results of that study.
+
+   The report documents the results of a task force on X.400(1988)
+   deployment of the RARE Mails and Messaging Work Group during the
+   period from November 1992 until October 1993. Open reviews of the
+   report have occurred in the RARE Mail and Messaging Work Group and
+   within the IETF X.400ops Working Group.
+
+   The scope of the report is limited to deployment of X.400(1988)
+   services, and as such the report does not contain any recommendations
+   on development and deployment of Internet RFC 822 / MIME/ PEM related
+   (pilot) services. However, since the report shows that both
+   X.400(1988) and RFC 822 / MIME / PEM will be developed and used
+   within the European R&D community, such a pilot should also
+   considered.  Note: RFC 822 is also known as Internet STD 11.
+
+   Circulation of this report is unlimited. Comments on this report may
+   be sent to the e-mail distribution list:
+
+    RFC 822: wg-msg@rare.nl
+    X.400:   S=wg-msg;O=rare;P=surf;A=400net;C=nl;
+
+Task Force Members:
+
+    Claudio Allocchio (INFN),
+    Harald T. Alvestrand (SINTEF),
+    James C. I. Craigie (JNT),
+    Urs Eppenberger (SWITCH),
+    Frode Hernes (maXware),
+    Jeroen Houttuin (RARE),
+    Erik Huizer (SURFnet) - chairman,
+    Steve Kille (ISODE Consortium),
+    James A. (Jim) Romaguera (NetConsult).
+
+    Editors: James A. (Jim) Romaguera & Erik Huizer
+
+   The work of this Task Force has been funded by the Commission of
+   European Communities (CEC) VALUE subprogram II, Stichting SURF and
+   SURFnet bv.
+
+
+
+
+
+
+RARE WG-MSG Task Force 88                                       [Page 2]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+Table of Contents
+
+   1.  Abstract                                                      1
+   2.  Management Summary                                            3
+   3.  Framework for the report                                      6
+   4.  Present situation of European Messaging                       7
+      4.1. Messaging services                                        7
+      4.2. Requirements for messaging                                8
+             4.2.1. User Oriented                                    9
+             4.2.2. Service provider viewpoint                      10
+      4.3. Messaging capabilities                                   11
+   5.  Possible solutions for providing globally pervasive
+       messaging                                                    12
+      5.1. PC LAN E-mail systems                                    13
+      5.2. RFC 822, MIME and PEM services                           15
+      5.3. X.400 - 1984 and 1988                                    19
+   6.  Migration to X.400(1988)                                     23
+      6.1. PC LAN E-mail systems                                    25
+      6.2. RFC 822, MIME and PEM services                           25
+      6.3. X.400(1984) services                                     27
+      6.4. Mail-11 services                                         28
+   7.  Benefits of migrating to X.400(1988) and the involved costs  28
+   8.  Main Recommendations                                         33
+   9.  Security Considerations                                      34
+   10. Reading List and Bibliography                                35
+   11. Terminology                                                  37
+   Appendix A - Elaboration on the main recommendations             38
+   Appendix B - A number of detailed guidelines.                    40
+   Authors' Addresses                                               44
+
+2.  Management Summary
+
+   This document reports the results of study of the X.400(1988) aspects
+   of messaging and their impact on the R&D community. The study was
+   funded by the CEC under VALUE Subprogram II and has been carried out
+   by a task force on the RARE Mail Working Group.  The document is
+   targeted at technical decision makers as well as those who would fund
+   activity in this area.
+
+   The document presents the existing situation as regards the
+   predominate messaging technologies within Europe. These are presented
+   within the context of a number of large messaging communities that
+   are using these technologies:
+
+    - RFC 822,
+    - X.400(1984),
+    - Mail-11 and
+    - PC LAN messaging
+
+
+
+RARE WG-MSG Task Force 88                                       [Page 3]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+   Three major European communities are referenced:
+
+    - Commercial service providers
+    - R&D community
+    - Commercial organisations using messaging services.
+
+   The report states the following facts:
+
+    - The resources, human or financial, to operate multiple wide
+      area messaging services connecting together independent
+      organisations are high. As such it is desirable to try and
+      keep to a minimum the number of such services. This statement
+      is true for the R&D community but is also highly likely to be
+      valid for the general European industry.
+
+    - There are two publicly available technological standards
+      that can be used by open communities, such as the R&D
+      community and public service providers: the X.400(1984 and
+      1988) recommendations and the Internet RFC 822 / MIME / PEM
+      standards.
+
+    - There is an established very large global user base of
+      Internet RFC 822 and X.400(1984) messaging services. Both
+      services have their own momentum within different parts of
+      the user community, both are still developing and growing
+      fast.
+
+   The report concludes that X.400(1988) will be the preferred protocol
+   for inter organizational connection for European industry and
+   government and parts of the European R&D community.  RFC 822 / MIME /
+   PEM will be the preferred protocol suite for inter-organisational
+   connection for the Internet community and, as products are already
+   widely available, it is the preferred protocol for parts of the
+   European R&D community.
+
+   The goal of European pervasive messaging - incorporating Industry,
+   Government and Academia - would be best accommodated and reached by
+   the establishment of a single messaging service.  However taking the
+   above into account, this is not feasible, as X.400(84 and 88) and RFC
+   822( and MIME) based services will be around for a long time to come.
+   To increase the functionality of Wide Area E-mail services there is a
+   clear necessity to:
+
+    - migrate RFC 822 services to a RFC 822 / MIME / PEM service.
+      A MIME based service offers more functionality to the user
+      than a plain RFC 822 service.
+
+    - migrate existing X.400 services to a X.400(1988) service.
+
+
+
+RARE WG-MSG Task Force 88                                       [Page 4]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+      Due to the lack of scalability of the X.400(1984) service in
+      terms of extra functionality, it will become increasingly
+      difficult to meet the needs of research users of existing
+      X.400(1984) services unless an X.400(1988) service is put
+      into place.
+
+    - provide a transparent gateway between X.400(1988) and RFC
+      822/MIME/PEM. For the European R&D community it is essential
+      to have a transparent gateway between the X.400(1988) service
+      and the RFC 822 / MIME / PEM service, thus ensuring
+      connectivity between these two services with a maximum
+      functionality.
+
+   Such a gateway is technically feasible and it is an essential part of
+   an unified E-mail service. Without such a standardised gateway the
+   overall E-mail service would deteriorate.
+
+   The lack of open standards for the PC LAN messaging systems
+   discourages their use as 'backbone' messaging technologies within
+   open communities. However the products that these systems deliver to
+   end users ensures that their already large share of the messaging
+   market will continue to exist for some time. Thus it is also
+   essential that strategies that allow these systems to be 'seamlessly'
+   integrated within the global messaging community are put in place.
+   Not least due to the indications that the main messaging vendors are
+   developing X.400(1988) and RFC 822/MIME gateways, a strategy to link
+   these systems together via X.400 and RFC 822 should be developed.
+
+   The report concludes with a set of recommendations, the main one
+   being the establishment of a X.400(1988) European pilot messaging
+   service for the R&D community. This pilot should include the
+   establishment of a transparent gateway service between X.400(1988)
+   and RFC 822/MIME. The goal of a European pilot is to ensure the
+   successful deployment of a European wide operational X.400(1988)
+   service that is pervasive and meets the needs of users. By collecting
+   together the issues related to the establishment of a European
+   X.400(1988) service, this report acts as a focal point and stimulant
+   for discussion on this topic within the R&D community. In the report
+   a summary of the benefits and problems of each of the above messaging
+   technologies within the context of achieving a global messaging
+   service, of which the R&D community is one part, is presented.
+   Further the document identifies issues, strategies and
+   recommendations related to the migration and coexistence of these
+   technologies within the scope of mainly the European R&D community
+   but also in relation to other messaging communities. A cost / benefit
+   analysis on the establishment of a European wide pilot X.400(1988)
+   messaging service is also presented. Finally a reading list of
+   references related to this subject has been compiled.
+
+
+
+RARE WG-MSG Task Force 88                                       [Page 5]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+   The report does not include any recommendations on development and
+   deployment of RFC 822 / MIME / PEM related (pilot) services, as these
+   are outside of the scope of the Task Force. However, since the report
+   shows that both X.400(1988) and RFC 822 / MIME / PEM will be
+   developed and used within the European R&D community, such a pilot
+   should also be considered.
+
+3.  Framework for the report
+
+   With the belief that user demands for new messaging services such as
+   Multimedia and Secure Messaging would develop, the RARE community
+   (together with other communities; most notably the Internet
+   Engineering Task Force (IETF)) has over the preceding years
+   experimented in new messaging and related technologies.  Experiments
+   and pilots, have been performed in messaging services e.g., as
+   recommended by CCITT X.400(1988) and Directory Services based upon
+   the CCITT X.500(1988) recommendations.
+
+   The results of such pilots and experiments indicate that it is now
+   opportune to commence a pilot X.400(1988) messaging service for the
+   European R&D community. The major goals of the pilot being, to
+
+    - establish a large scale European wide pilot messaging
+      service based on X.400(1988).
+
+    - collaborate with and facilitate the commencement of similar
+      pilot services within diverse communities; both R&D and non-
+      R&D (e.g., commercial ADMDs and PRMDs, etc.); both European
+      and non-European (e.g., North American , Asian, etc.).
+
+    - encourage and assist the development and deployment of a
+      wide variety of commercial and public domain X.400(1988)
+      messaging products that meet the user's needs, for instance
+      X.400(1988) products such as User Agents (UAs), Message
+      Stores (MSs), Message Transfer Agents (MTAs) and gateways
+      between X.400(1988) services and other widespread messaging
+      services i.e., RFC 822, Mail-11 and proprietary.
+
+    - prove that such a service and products efficiently meets the
+      existing and expected demands for new messaging services by
+      European R&D users. And as such determine the steps for a
+      European deployment of an operational X.400(1988) messaging
+      service.
+
+    - determine the needed steps to facilitate migration for the
+      existing operational R&D X.400(1984) based messaging service,
+      as represented by the R&D MHS service (the former COSINE
+      MHS), RFC 822 / MIME / PEM based messaging services and the
+
+
+
+RARE WG-MSG Task Force 88                                       [Page 6]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+      HEPnet / SPAN Mail-11 based messaging service to an
+      operational X.400(1988) messaging service. It is self evident
+      that during such migrations, transition steps must be
+      included that allow a period of coexistence, at the highest
+      possible service level, between X.400(1988), X.400(1984), RFC
+      822 / MIME and HEPnet / SPAN Mail-11 services.
+
+    - determine the needed steps that allow proprietary messaging
+      systems, that are widely deployed within the European R&D
+      community to be integrated at as high as possible service
+      level, by an X.400(1988) infrastructure.
+
+   This report identifies the issues involved in such a pilot service.
+   It is not a concrete proposal for such a project but the report
+   discusses advantages and disadvantages, costs and enefits and
+   migration issues for deploying a X.400(1988) service. As such it is a
+   discussion and feasibility paper on the creation of a large scale
+   European wide pilot X.400(1988) messaging service for the European
+   R&D community.
+
+4.  Present situation of European Messaging
+
+4.1. Messaging services
+
+   Electronic messaging within Europe can be viewed as a number of
+   messaging services communities. Three important communities comprise,
+
+    - Commercial e-mail networks,
+    - Research e-mail networks and
+    - PC LAN messaging systems.
+
+   Commercial e-mail networks are classified as either ADMDs or PRMDs.
+   ADMDs and PRMDs are operating in nearly every European country.
+
+    - ADMD services (or public commercial e-mail services) are
+      provided by over 50 service providers which have
+      interconnected using the X.400(1984) protocols. The topology
+      between these ADMDs, although not yet 'mesh', can be stated
+      as progressing quite rapidly to this optimum goal. However
+      there is still a way to go before ADMDs provide full European
+      connectivity.
+
+    - PRMDs (or private commercial e-mail service providers) have
+      interconnected to ADMDs and other PRMDs predominantly using
+      the X.400(1984) protocols but also with proprietary
+      protocols.
+
+
+
+
+
+RARE WG-MSG Task Force 88                                       [Page 7]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+   Research networks are providing messaging services in every European
+   country. These R&D service providers are operated as either ADMDs or
+   PRMDs and are using both X.400(1984) protocols and Internet RFC 822
+   protocols to connect to each other.
+
+   Moreover, there are also large R&D communities (i.e., HEPnet and
+   SPAN) using proprietary protocols (i.e., DECnet Phase IV and Mail-11)
+   as their main messaging systems. The DECnet IV based communities are
+   now migrating to DECnet Phase V (OSI connectionless protocol stack),
+   which provides X.400(1988) (plus X.400(1984)) as a major messaging
+   system.  In general, all these services are totally interconnected.
+   As such it is a statement of fact that there exists within the
+   European R&D community, two parallel interconnected messaging
+   infrastructures based upon X.400(1984) and RFC 822. However
+   interconnections between the R&D messaging community and the majority
+   of the European commercial service providers use the X.400(1984)
+   protocols.
+
+   It is also clear that the commercial world mostly makes inter-
+   organizational messaging interconnections using the X.400(1984)
+   protocols. And also that the commercial messaging world is not as
+   totally interconnected as the R&D messaging community.  Finally, for
+   a number of commercial and public organisations there is often a
+   mandatory requirement to use X.400 for messaging interconnections.
+
+   The usage of PC LAN messaging systems is increasing very rapidly
+   within the academic and commercial communities. In general, PC LAN
+   messaging services within both communities do not use X.400(1984) or
+   RFC 822 messaging systems but systems based upon proprietary
+   protocols. The PC LAN messaging systems can be considered more as
+   'Islands of Messaging' that gateway to the commercial and R&D
+   messaging services by using X.400(1984) or RFC 822 gateways. PC LAN
+   messaging systems within commercial organisations connect to
+   commercial service providers also via proprietary protocols. The PC
+   LAN messaging services, although probably comprising the largest
+   number of users, are in general poorly integrated with the global
+   messaging service (The Dutch, UK and Italian academic communities
+   confirm that there appears to be many such 'Islands' of PC LAN
+   messaging systems within their networks.).
+
+4.2. Requirements for messaging
+
+   Experience with existing global e-mail services has proven that with
+   the increased use of messaging, there follows an awareness of extra
+   requirements for related services. These requirements can be
+   classified into 'User based Requirements' and 'Service Provider based
+   Requirements' to either support, or exploit, high quality messaging
+   services. These requirements are elaborated upon within this chapter.
+
+
+
+RARE WG-MSG Task Force 88                                       [Page 8]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+4.2.1. User Oriented
+
+   The only thing a user requires is an easy to use, well integrated,
+   user interface to electronic mail. Usually the user does not care
+   what protocol is used. However there are certain inherent
+   requirements to the functionality that can be identified as user
+   requirements. The main user requirements identified are:
+
+   - Distribution Lists (DLs)
+
+      A widely perceived omission from the X.400(1984) recommendations
+      was the lack of support of DLs. Distribution lists allow users to
+      enlist themselves onto electronic mail expander lists
+      (distribution lists). A message to such a distribution list will
+      automatically, and without significant delay, be sent on to anyone
+      whose electronic mail address is on that list. Such a list can be
+      a public list, that is meant for discussions on a specific
+      subject, much like a sort of "magazine". However the list can also
+      be a "closed" list, containing only a selected set of people who
+      need to communicate privately, e.g., a project-team.
+
+   - Multinational language and Multimedia support
+
+      European users have for many years been frustrated in their
+      inability to use their national character sets when communicating
+      using messaging systems. The problems within e-mail systems that
+      were causing this character set frustration are at their base the
+      same problem that would get in the way of Multimedia messaging
+      like:
+
+         - lack of binary data support
+         - lack of standardised encoding schema's
+         - definition of multiple body-parts
+
+      The enormous potential of Multimedia systems and services
+      (especially within the commercial community as evidenced by the
+      enormous press publicity and mega-mergers positioning companies to
+      exploit this technology but also within the government spheres
+      i.e., the U.S.A. Government's 'Information Superhighway'
+      initiative) has acted as a spur to make rapid progress in solving
+      the problems in this area.
+
+   - White pages Directory Service
+
+      A white pages directory service provides a unique but very basic
+      and important service; a way to store and find information about
+      people and resources that is analogous to a telephone service's
+      paper based directory i.e., White Pages. User's E-mail addresses
+
+
+
+RARE WG-MSG Task Force 88                                       [Page 9]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+      can be stored for subsequent retrieval by E-mail systems.
+
+   - EDI
+
+      EDI today is not extensively used within the academic environment.
+      However there is a distinct potential within the academic
+      community to reduce costs and improve services with EDI. Potential
+      EDI uses could be,
+
+         - EDI between universities
+         - EDI between universities and government
+         - EDI between universities and lower level educational
+           institutions (e.g., student records)
+         - Commercial EDI using the Internet as an infrastructure.
+
+      The significance of maintaining end to end integrity (especially
+      security aspects) of the EDI messages mandates that no gateways
+      should be used between originator and recipient.
+
+   - Support of Security services
+
+      E-mail as it is currently used is far from secure. To allow for
+      serious usage of E-mail security issues need to be addressed,
+      like:
+
+         - integrity; making sure that the message is transferred
+           intact, without any changes or additions.
+         - encryption; making sure the message content is only
+           decipherable by the intended recipient.
+         - authentication; making sure that the originator and/or
+           recipient are authenticated.
+
+4.2.2. Service provider viewpoint
+
+   The task force believes the following points as being the most
+   significant service provider requirements:
+
+   - Network Management
+
+      This area is still very new, in terms of offering standardised
+      protocols, services and products for management. However a minimum
+      'goal' is to provide for central management functions that will
+      allow providers to offer a better quality of service.  There is
+      presently ongoing work within the IETF Working Group MADMAN to
+      define SNMP monitoring and managing of E-mail systems, gateways
+      and X.500 directory systems. A number of management areas that
+      need to be worked upon include: QOS, Service Level Agreements
+      (SLAs), Multiple system queue management, Accounting, Routing Co-
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 10]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+      ordination and Message Tracing.
+
+   - Support of MTA routing
+
+      Dynamic routing from MTA to MTA, relieves the necessity to
+      maintain large routing tables, especially within a large PRMD, or
+      community of PRMDs (like the R&D MHS community).
+
+   - Address mapping between RFC 822 and X.400
+
+      The widespread use of X.500 or DNS for mapping, allows a reduction
+      of manpower for centrally co-ordinating globally consistent
+      X.400-to-RFC-822 mapping tables and distributes the responsibility
+      for updating the mapping rules. This should allow mapping rules to
+      change when needed and to be available immediately.
+
+   - UA capabilities registration
+
+      The use of the directory to register UA capabilities for
+      X.400(1988), X.400(1984) and RFC 822 / MIME / PEM systems is a
+      very desirable benefit for users in terms of speeding the
+      deployment of new messaging services (e.g., Multimedia Messaging).
+
+4.3. Messaging capabilities
+
+   Due to the problems of gatewaying within a multi-protocol messaging
+   environment, the great majority of R&D E-mail users are reduced to
+   using only InterPersonal Messaging (IPM) services based upon the
+   exchange of message body parts using CCITT character set IA5 (US
+   ASCII).
+
+   Within the R&D community recent work to meet user requirements for
+   non ASCII messaging services - as documented above - has resulted in
+   enhancements to the messaging services based upon RFC 822 protocols.
+   The enhancements provide Multimedia support via the Multipurpose
+   Internet Mail Extensions (MIME) and the prospect in the very near
+   future of secure messaging via Privacy Enhanced Mail (PEM).
+   Deployment of the MIME enhanced RFC 822 based services, via
+   distribution of software and the setting up of the needed
+   organisational structures, has commenced. The PEM enhancements are in
+   a large scale pilot phase e.g., VALUE PASSWORD project.
+
+   In the case of X.400(1984) the usage of non ASCII body parts is
+   mostly effected by bilateral agreement between recipient and
+   originator, through use of body part 14. In practice this restricts
+   the exchange of non ASCII body parts to those cases where the
+   recipient and the originator use the same bilateral agreement or else
+   the originator includes an ASCII message explaining the included
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 11]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+   content type. Besides IPM there is a growing usage of EDI on top of
+   X.400(1984).
+
+   With the above X.400(1984) deficiencies in mind, X.400(1988) has been
+   specified by the CCITT / ISO to meet new user demands.  X.400(1988)
+   provides support for various different body parts, enhanced security
+   features, international character set support capabilities and
+   support of X.500 Directory Services. Due to the technological
+   potential of these standards to satisfy user needs for new messaging
+   services, the R&D community has been experimenting and piloting
+   X.400(1988) and X.500(1988) services.  As there is a strong
+   dependency of X.400(1988) messaging upon X.500(1988) directory
+   services, the necessary precondition to supply these user demands is
+   a deployed and operational X.500(1988) directory service. Piloting
+   and deployment of the X.500(1988) directory service within the R&D
+   community has been successfully initiated and co-ordinated by the
+   COSINE and the VALUE PARADISE projects.
+
+   Similarly, secure messaging has been addressed by the VALUE PASSWORD
+   project and the RARE and IETF communities. Work to solve problems
+   related to directory support of X.400(1988) messaging has been
+   pursued within the IETF and RARE. The relevant RARE and IETF work
+   groups (e.g., RARE WG-MSG, IETF MHS-DS, etc.) have also worked to
+   produce any needed enhancements to the base X.400(1988) and
+   X.500(1988) standards.  Last but not least it should not be
+   overlooked that X.400(1988), as compared to X.400(1984), provides a
+   comprehensive basis for gatewaying to and from RFC 822 / MIME / PEM
+   and PC LAN messaging services. To that respect the IETF has defined
+   standards for gatewaying Multimedia mail between RFC 822 / MIME / PEM
+   and X.400(1988). As RFC 822 / MIME / PEM is now being deployed on the
+   Internet, deployment of X.400(1988) services is needed to assure
+   multimedia and secure messaging connectivity for the European R&D
+   community.
+
+5.  Possible solutions for providing globally pervasive messaging
+
+   As can be now seen, a correlation of the present situation to the
+   requirements of the user, shows that the current messaging services
+   do not match the needs of users. To try to meet these needs a number
+   of developments within various messaging technology areas are
+   occurring. The following messaging technological areas, due to the
+   present installed user base within the R&D community, are considered
+   relevant:
+
+      - PC LAN E-mail systems such as Lotus cc:Mail, Microsoft Mail
+        and Novell MHS
+      - RFC 822 / MIME / PEM E-mail services
+      - X.400(1988) messaging services
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 12]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+
+   Ongoing developments within each of the above technological areas
+   provide new messaging options for the R&D community. The ability of
+   each technological area to provide solutions for user and service
+   provider requirements is summarised within this chapter.
+
+5.1. PC LAN E-mail systems
+
+   Currently the usage of PC LAN E-mail systems is mostly for internal
+   communication within an organisation. External connections, if
+   present at all, to public service providers or other organisations is
+   mostly through gateways to X.400(1984) or RFC 822. The use of a PC
+   LAN E-mail system in terms of an infrastructure for interconnecting
+   E-mail systems of different hues is not common within the Research
+   community.  Recent experience, from amongst others the Dutch Research
+   network - SURFnet - [14] and the Norwegian Directorate for Public
+   Management - Statskonsult - [18], has shown that a number of problems
+   (i.e., limited functionality, high operational management cost, etc.)
+   can be expected should these PC LAN E-mail systems be used as an E-
+   mail infrastructure. (The use of native X.400 protocols for PC LAN
+   E-mail systems would avoid the usage of gateways and would thus
+   alleviate many of these problems.) A summary of those problems and
+   some relevant issues follows:
+
+   -  Interconnecting heterogeneous PC LAN messaging systems
+
+      One very distinct benefit for E-mail users of all hues is the
+      potential to integrate heterogeneous PC LAN messaging systems with
+      a minimum loss of service (e.g., multimedia services) by
+      connecting them via X.400(1988) (or RFC 822/MIME/SMTP).
+      X.400(1988) is already being used, or under active development,
+      for connecting together PC LAN messaging systems in a number of
+      environments (e.g., Apple Macintoshes, DEC, Microsoft, Lotus,
+      etc.). This tendency to gateway PC LAN messaging systems via
+      X.400(1988) will increase and is one of the benefits that
+      X.400(1988) brings to global multiprotocol messaging.
+
+   - Multimedia and binary data support
+
+      The benefit of E-mail systems using these PC LAN systems is that
+      the user interfaces are usually well integrated in the users
+      standard working environment. Using a proprietary protocol these
+      systems allow not only text (ASCII) but also binary, word
+      processor, video, audio and other types of files to be
+      transported. To reap the benefits of this multimedia / binary data
+      transfer it would normally require that the same type of gateway
+      is used by sender and receiver. Transporting these same files to
+      another type of PC LAN E-mail system is not possible through the
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 13]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+      current gateways without some information loss. In effect PC LAN
+      E-mail system's X.400 (or RFC 822) gateways from different vendors
+      perform acceptably only for text body parts.  True heterogeneous
+      multimedia PC LAN messaging needs gateways to X.400(1988)'s
+      service.
+
+   - Application Programming Interfaces
+
+      To help solve the problem of portability for Mail Enabled
+      Applications Microsoft, Lotus, Novell, XAPIA and X/OPEN have been
+      working on a number of standards for the Application Interface to
+      mail transport protocols (i.e., Mail Application Programming
+      Interface - MAPI, Vendor Independent Messaging - VIM, Common Mail
+      Calls - CMC). These efforts are structured independent of the
+      existing 'Wide-Area' or inter organisational E-mail protocols of
+      X.400(1984) and RFC 822. However the MAPI, VIM and CMC efforts,
+      due to their proposers (respectively Microsoft, Lotus and X/OPEN),
+      do look like they will provide the stimulant to various software
+      developers to develop more portable applications plus allow the
+      rich functionality of X.400(1988) to be accessed by these
+      applications thus reducing the need for gatewaying to X.400(1988).
+
+   - Security
+
+      As the PC LAN E-mail systems require gateways for connectivity,
+      they pose a problem with regard to encrypted messages.  Gatewaying
+      of secure messages is normally not possible. The gatewaying of
+      secure messages is a general problem of gatewaying from one mail
+      system to any other system and is not specific to PC LAN E-mail
+      systems.
+
+   - Directory Services
+
+      To date mostly proprietary directory services have been deployed
+      that do not match the needs of the users in terms of access
+      controls for data, distributed and decentralised across
+      organisations. X.500 based services promise solutions to such
+      needs. As a result various suppliers have announced support of
+      X.500 directory services for their E-mail products. However,
+      should these interfaces be delayed then support of an inter
+      organisational 'White Pages' services requires either,
+
+      - directory information exchange products (i.e., directory
+        gateways) deployed between a proprietary system and an X.500
+        directory system
+
+
+
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 14]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+      - gateways between de-facto market based proprietary
+        standards, such as Retix Directory Exchange (DX) or
+        Soft*switch's Directory Synchronisation (DS), and X.500
+        protocols
+
+      - duplicated directories i.e., one proprietary and one X.500
+        need to be operated.
+
+   It should be stressed that gatewaying mechanisms and products are
+   often problematic due to the lack of an open standard on the
+   proprietary messaging system and or directory system. (As an aside it
+   is thus essential to establish an operational X.500 infrastructure,
+   including E-mail user interfaces that can transparently access this
+   Directory Service, as soon as possible.)
+
+5.2. RFC 822, MIME and PEM services
+
+   RFC 822 messaging services are widely deployed within the R&D
+   community. There is ongoing work to extend RFC 822 to meet user
+   requirements. Some of these extensions are elaborated upon within
+   this chapter.
+
+   - Distribution lists
+
+      RFC 822 allows for the usage of DLs. Management of DLs is not
+      (yet) standardised.
+
+   - RFC 822 multimedia messaging via MIME
+
+      With the arrival of MIME, the RFC 822 service has an additional
+      protocol standard that addresses Multimedia messaging very
+      comprehensively. In terms of user needs, MIME now allows messaging
+      body parts to comprise multinational character sets and binary
+      data. Multi-body part messages are also supported.  One of MIME's
+      real strengths, in terms of deployment within the existing RFC 822
+      service, is that it achieves its goals by overlaying its services
+      over the existing RFC 822 service and thus mandating no changes to
+      the in place RFC 822 infrastructure. This greatly simplifies the
+      MIME deployment.
+
+   - RFC 822 secure messaging via PEM
+
+      Just as MIME has brought multimedia messaging to RFC 822 services,
+      Privacy Enhanced Mail (PEM) is bringing secure messaging to RFC
+      822 services. PEM also has used the same approach as MIME to
+      deploy secure messaging within RFC 822 services; overlay PEM
+      services over the existing RFC 822 services without requiring
+      changes to the RFC 822 infrastructure. PEM brings confidentiality
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 15]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+      and integrity of messages to RFC 822 users. However a number of
+      problems with PEM, and X.400(1988) as well, still need to be
+      solved before secure messaging can be considered to be an
+      operational service.  These problems are independent of the secure
+      messaging protocol (i.e., PEM or X.400(1988)) and deal mainly with
+      distribution of secret keys to the end users. There is very active
+      work going on within the IETF to solve these problems.
+
+   - MIME and PEM
+
+      There are still problems for messages that are simultaneously a
+      multimedia message, as per MIME, and a secure message, as per PEM.
+      A PEM encoded MIME message does not allow gatewaying to other
+      messaging environments and therefore does not allow any of the
+      features inherent within MIME to be exploited along the message
+      path. A MIME message that contains PEM encoded body parts can be
+      gatewayed but the integrity of the entire message is then not
+      guaranteed. This is a real deficiency of both existing approaches
+      as it is essential that users are able to simultaneously use
+      multimedia and secure messaging. However, once again, the IETF is
+      working very hard on solving these problems and solutions can be
+      expected, although the solution of the gatewaying of PEM messages
+      to other E-mail systems is still unclear.
+
+   - Dynamic and distributed messaging routing via the Domain Name
+     System (DNS)
+
+      RFC 822 messaging benefits greatly by having a dynamic and
+      distributed mechanism to assist in message routing i.e., Domain
+      Name System (DNS). With the support of the DNS, RFC 822 MTAs are
+      able to directly route to other RFC 822 MTAs and thus deliver
+      messages with a minimum of delay. In practice mail often still
+      traverses multiple RFC 822 MTAs for a number of reasons e.g., Mail
+      Hubs provided for users who turn their machine off when they go
+      home, Firewall Hubs for security reasons, etc. However it is
+      commonly accepted that between RFC 822 mail hubs the delivery of
+      messages is very fast. Typically resolution of routing decisions
+      occurs in less than one minute and very often within seconds. In
+      general the DNS service is a very valuable service that functions
+      well in practice.
+
+   - Support for Character sets
+
+      Together with the MIME specification for content types, an
+      extension for RFC 822 headers was defined that allows for usage of
+      multiple character sets in names, subject etc. in RFC 822 headers
+      [9]. This allows (European) users to use their preferred character
+      set to support their language not only in the contents of a
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 16]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+      message but also in the headers.
+
+   - MIME capable gateways
+
+      It is clear that to provide a seamless service to all users
+      regardless of whether they are using RFC 822 or X.400 services, a
+      widely available set of well run and standardised RFC 822 to X.400
+      gateways must be in place. For InterPersonal Messaging (IPM) based
+      on US ASCII there are already a large number of such standardised
+      (i.e., X.400-to-RFC 822) gateways deployed. To ensure seamless
+      gatewaying between MIME and X.400 multimedia users, these existing
+      text based gateways must be either upgraded to or replaced with
+      multimedia messaging gateways. A number of proposed Internet
+      standards to solve these problems, for both X.400(1984) and
+      X.400(1988) and generated within the MIMEMHS work group of the
+      IETF, have been completed [4].
+
+   - Access to fax, teletex, telex or physical delivery
+
+      For the moment, there is no standardised way for RFC 822 users to
+      access gateways to the above services except by indirect access to
+      X.400(1988) systems (i.e., concatenated gateways of RFC 822 to
+      X.400(1988) and then onwards to the appropriate X.400(1988) Access
+      Unit). Although even this indirect method would require some
+      further work on standardising mappings between RFC 822 addresses
+      and X.400(1992)'s X.121 addresses. As well some experiments within
+      the RFC 822 world are occurring on routing fax messages.
+
+   - Operational support
+
+      Generally, RFC 822 messaging services are delivered on a 'best
+      effort' basis and thus service level agreements requesting
+      stringent response times to operational problems or guaranteed
+      delivery times for messages are difficult to agree. This phenomena
+      might be a result of the distribution and delegation of authority
+      to organisations updating the RFC 822 MTA's routing mechanism
+      i.e., DNS. As a result it makes it hard to reach a 'one stop
+      shopping' agreement for RFC 822 messaging services.
+
+   - Notifications
+
+      The RFC 822 service provides a minimum amount of base protocol
+      support for messaging users. It could be argued that the RFC 822
+      protocol is simplified by this choice and thus software that
+      implements the standard need be smaller in size and easier to
+      build. However some features e.g., delivery & receipt
+      notifications and UA capabilities registration, would be commonly
+      accepted as being desirable from a user standpoint and thus
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 17]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+      desirable extensions to RFC 822. Some operational problems
+      relating to reliability could be minimised by technology that has
+      a standardised support for positive and negative notifications of
+      messages. RFC 822, as compared to X.400, technology does not yet
+      support positive notifications (although there is work starting
+      within the IETF to extend RFC 822 to support delivery
+      notifications). However within RFC 821 transport system (i.e.,
+      SMTP) there are standardised negative notifications that work
+      well.  Alternatively X.400 technology, deployed over TCP/IP (using
+      STD 35, RFC 1006), may help to address the lack of adequate
+      service quality - notification support - when using E-mail within
+      the Internet.
+
+   - Portability of RFC 822 products
+
+      There are only a few mailbox formats in general use by RFC 822
+      software, one being the 'bin/mail' format and the other 'MH'
+      format.  This 'standard' mailbox format is a definite benefit for
+      RFC 822 users as it allows them to change RFC 822 UAs (e.g.,
+      upgrading to MIME RFC 822 UAs) whilst not compromising or
+      converting their existing archived mail, which may comprise 1000s
+      of archived messages.
+
+   - System support for RFC 822 products
+
+      Normally, RFC 822 MTAs and UAs come pre-installed on UNIX
+      workstations. As a result, users are spared the effort of
+      installing RFC 822 MTA software. If for some reason, a user or
+      mail administrator should wish to install a different MTA or UA to
+      the pre-installed system, there exists a large number of easily
+      available (i.e., via widespread distribution amongst many FTP and
+      other information servers) public domain RFC 822 MTAs and UAs.
+
+      Both of the above points encourages the spread and eases the
+      installation of software for the RFC 822 messaging service and in
+      many ways explains the size and importance of the installed base
+      of RFC 822 systems. To illustrate the extent of RFC 822 / MIME
+      products, a non-comprehensive list of available MIME enhanced RFC
+      822 products follows; ELM 2.4, MH 6.8, Sun Mailtool, HP Mpower
+      Desktop, Lotus cc:Mail (unconfirmed), Zcode Zmail, Frontier
+      Super-TCP for Windows, PMDF (VAX VMS), Pine, C-Client (library
+      routines), Metamail (viewer only), Andrew-MIME gateway.
+
+   - UA capability registration
+
+      The IETF MHS-DS working group has defined how X.400 and RFC 822
+      User Agent capabilities can be stored in X.500 directory services.
+      This work is still ongoing.
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 18]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+5.3. X.400 - 1984 and 1988
+
+   X.400(1988) substantially upgrades and enhances the X.400(1984)
+   standards. A number of new functions have been incorporated within
+   X.400(1988). A description of the most important features of X.400 -
+   1984 and 1988 - follows.
+
+   - Notifications
+
+      X.400(1984) provides four notifications - positive and negative
+      delivery notifications and positive and negative receipt
+      notifications. These notifications allow users to ensure
+      successful message delivery or that the message was read. The
+      delivery notifications are also used by service operators in their
+      fault escalation procedures.
+
+   - Binary Data Transfer
+
+      X.400(1984) allows binary data transfer to be transported without
+      the necessity of character encoding. The ability to transfer files
+      of whatever type is a valuable end user service.  As well the lack
+      of any necessary character encoding allows users to utilise the
+      received data without needing any character decoding software.
+
+   - Multiple Body Parts
+
+      The ability to send multiple body parts within one message gives
+      the user the ability to send multiple logical components within
+      one message. This is a natural mechanism for users as it mirrors
+      the real life situation of being able to send within one message,
+      a letter, a word processor file, a spreadsheet file, etc.
+
+   - Feature rich messaging model
+
+      The features of X.400 are very rich. This provides benefits for
+      users as vendors are able to provide applications that can utilise
+      these extensive features in an interoperable manner due to the
+      standardisation of the features within X.400.
+
+   - Clear messaging model
+
+      X.400(1984), as one of its most wide reaching achievements, has
+      popularised within the market a consistent and clear model to
+      describe message handling systems. The decomposition of a message
+      handling system into UAs, MSs, MTAs, MTS - ADMDs and PRMDs and
+      Access Units / Gateways has proved to be an extremely useful tool
+      for users and vendors to understand and communicate their
+      messaging needs or solutions.
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 19]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+   - Multiple lower layer networks
+
+      X.400 has embraced the concept that there are different technology
+      lower layer networks. This concept even allows multiple logical
+      networks of the same technology to be supported. X.400 allows the
+      messaging service to fully function even though the underlying
+      network is varying. In the real world of a non-uniform network
+      layer this is an extremely powerful capability.
+
+   The list of major X.400(1988) extensions to X.400(1984) follows:
+
+   - Distribution Lists (DLs)
+
+      A powerful mechanism for arbitrarily nested Distribution Lists
+      including the ability for DL owners to control access to their
+      lists and to control the destination of non delivery reports.  The
+      current endemic use of DLs in the R&D community makes this a
+      fundamental requirement for any service. X.400(1988) uses X.500 to
+      provide a standardised support for DLs, although there have been
+      some needed standardised enhancements relating to the CCITT
+      defined DLs by the IETF MHS-DS work group. The provision of
+      powerful nesting capabilities plus management mechanisms for DL
+      owners within X.400(1988) DLs are features providing attractive
+      benefits for users and DL managers.  There is already 'running
+      code', via the COSINE Explode project which is implementing the
+      MHS-DS based enhancements. The project builds upon experience
+      gained within a number of networks e.g., JNT and provides:
+
+         - implementation of MHS-DS enhancements related to the
+           X.400(1988) DLs
+         - archiving of messages received by a DL.
+         - access by users to the DL archive via e-mail.
+         - subscription to a DL by users via e-mail.
+
+   - Message Store (MS)
+
+      The Message Store provides a server for remote UAs on workstations
+      and PCs enabling messages to be held for their recipient, solving
+      the problems of non-continuous availability of such UAs. The
+      message store allows mobile workers, small offices and local
+      schools to become active messaging users in a cost effective
+      manner. The message store provides powerful selection mechanisms
+      allowing the user to select messages to be transferred between the
+      store and the workstation. This facility is not catered for
+      adequately by the P3 protocol of X.400(1984) and provides a major
+      incentive for transition.
+
+
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 20]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+   - X.500 Directory names
+
+      Support for use of Directory Names in MHS will allow a transition
+      from use of O/R addresses to Directory Names when X.500
+      Directories become widespread, thus removing the need for users to
+      know about MHS topological addressing components.
+
+      The ability for X.400(1988) messages to contain directory names
+      instead of the O/R addresses is a powerful feature for users as it
+      frees them of the necessity to insert O/R addresses containing
+      routing information but allows them to insert the more natural
+      directory names. However, the management of the large amounts of
+      distributed data contained within the directory is problematic in
+      that it involves a number of organisational issues and not just
+      software issues. A number of X.400(1988) UAs which allow users to
+      insert directory names instead of O/R addresses have already been
+      developed.
+
+   - Support for EDI
+
+      Through the definition of Pedi, as defined in X.435, X.400(1988)
+      offers integrated support for EDI messaging. The CEC TEDIS program
+      has mandated X.400 as the main carrier for EDI, and standardised
+      how EDI transactions are inserted into X.400 messages (i.e., Pedi
+      and P2). This provides a strong incentive to provide native
+      X.400(1988) services to users and applications thus encouraging
+      commercial EDI traffic to migrate to X.400(1988).
+
+   - Secure Messaging
+
+      The provision of secure messaging services including
+      authentication, confidentiality, integrity and non-repudiation as
+      well as secure access between MHS components are important
+      benefits for the R&D community. The base standards are adequate
+      for security, however organisational and software issues need
+      still to be solved. Organisational issues of globally scaling the
+      distribution of secret keys is still unsolved. Software issues of
+      how end users will be able to comfortably and securely input
+      secret keys of length 512 -> 1024 bits into security software need
+      to be solved.
+
+   - Multimedia
+
+      The definition of a number of additional body parts plus the
+      ability to define new body parts (e.g., Word Processor formats,
+      Excel documents, etc.) provides the basis for multimedia services
+      over X.400(1988). As well, the newly defined General Text body
+      part supports multinational character sets (except for ISO 10646)
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 21]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+      without the need for transmission encoding. However, unlike MIME,
+      X.400(1988) is only specifying a standard for multimedia
+      messaging. To achieve multimedia document exchange, there is a
+      further text exchange standard such as ODIF, Hytime, etc., needed.
+
+   - Character set support for extended addressing
+
+      A highly desirable potential benefit for European R&D users is
+      provided by the extended character set support(i.e., T.61) within
+      addresses. Nearly all European languages, except for Greek and
+      Cyrillic, are supported by the T.61 teletex encoding. Further
+      extensions to X.400 for support of extended character sets has
+      been defined by the RARE WG on character sets and RARE WG on
+      messaging [15].
+
+   - Physical Delivery Services
+
+      This standardised method for a message to be delivered on a
+      physical medium, such as paper, through the normal postal service
+      is useful when trying to reach a very wide number of (non-
+      electronically reachable) recipients. In effect this service
+      provides an ability to 'go the last mile' and communicate with
+      users previously not easily reachable e.g., farmers, etc.
+
+   - General Extension Mechanism
+
+      One of the major assets of X.400(1988) is the extension mechanism.
+      This is used to carry most of the extensions defined in these
+      standards, but its principal benefit will be in reducing the
+      trauma of transitions to future versions of the standards.
+
+      Provided that implementations of the X.400(1988) standards do not
+      try to place restrictions on the values that may be present, any
+      future extension will be relayed by these implementations when the
+      extension is not critical, thus providing a painless migration to
+      new versions (1992 and beyond) of the standards.
+
+   - UA Capability Registration
+
+      With the extra functionality available to X.400(1988 and
+      especially 1992) UAs (i.e., extra non-IA5 body parts, secure
+      messaging, etc.) it is expected that the demand to register UA
+      capabilities will increase. In that respect X.400(1988)'s ability
+      to query X.500, where such capabilities would be stored, is a
+      significant potential benefit for users.
+
+
+
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 22]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+   - X.500 support for MTA routing
+
+      The piloting of X.500 to support MTA routing within the R&D
+      community has already commenced, on a small experimental scale,
+      via the Longbud project co-ordinated by the IETF MHS-DS work
+      group. Some concrete benefits promised by X.500 based routing are:
+
+      - routing based upon content types, security, transport stacks
+        and other criteria allow optimum routing paths to a
+        destination MTA to be chosen. (There is presently no such
+        similar capability within the DNS).
+
+      - allowing the routing information to be inserted and modified
+        in a distributed manner reduces (if not eliminates) the
+        necessity of central distribution of static routing tables.
+        The consequent reduction in manpower to co-ordinate MTA
+        routing plus the increase in scalability of the service
+        allows a truly global messaging service to be put in place.
+
+6.  Migration to X.400(1988)
+
+   What is clear from the previous chapters is that;
+
+      - The resources, human or financial, to operate multiple wide
+        area messaging services connecting together independent
+        organisations are high. As such it is desirable to try and
+        keep to a minimum the number of such services. This statement
+        is true for the R&D community but is also highly likely to be
+        valid for the general European industry.
+
+      - There are two publicly available technological standards
+        that can be used by open communities, such as the R&D
+        community and public service providers: the X.400(1984 and
+        1988) recommendations and the Internet RFC 822 / MIME / PEM
+        standards.
+
+      - There is an established very large global user base of
+        Internet RFC 822 and X.400(1984) messaging services. Both
+        services have their own momentum within different parts of
+        the user community, both are still developing and growing
+        fast.
+
+   From the above discussion, it is clear that the infrastructure
+   services that have to be supported within these open communities, and
+   especially within the R&D community, are RFC 822 / MIME / PEM,
+   X.400(1984) and X.400(1988). X.400(1988) will be the preferred
+   protocol for inter-organisational connection for European industry
+   and government and parts of the European R&D community. RFC 822 /
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 23]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+   MIME / PEM will be the preferred protocol suite for inter-
+   organisational connection for the Internet community and, as products
+   are already widely available, it is the preferred protocol for parts
+   of the European R&D community.
+
+   The goal of European pervasive messaging - incorporating Industry,
+   Government and Academia - would be best accommodated and reached by
+   the establishment of a single messaging service.  However taking the
+   above into account, this is not feasible, as X.400 and RFC 822 based
+   services will be around for a long time to come. To increase the
+   functionality of Wide Area E-mail services there is a clear necessity
+   to:
+
+      - migrate RFC 822 services to a RFC 822 / MIME / PEM service.
+        A MIME based service offers more functionality to the user
+        than a plain RFC 822 service.
+
+      - migrate existing X.400 services to a X.400(1988) service.
+        Due to the lack of scalability of the X.400(1984) service in
+        terms of extra functionality, it will become increasingly
+        difficult to meet the needs of research users of existing
+        X.400(1984) services unless an X.400(1988) service is put
+        into place.
+
+      - provide a transparent gateway between X.400(1988) and RFC
+        822/MIME/PEM. For the European R&D community it is essential
+        to have a transparent gateway between the X.400(1988) service
+        and the RFC 822 / MIME / PEM service, thus ensuring
+        connectivity between these two services with a maximum
+        functionality.
+
+   Such a gateway is technically feasible and it is an essential part of
+   an unified E-mail service. Without such a standardised gateway the
+   overall E-mail service would deteriorate.
+
+   The lack of open standards for the PC LAN messaging systems
+   discourages their use as 'backbone' messaging technologies within
+   open communities. However the products that these systems deliver to
+   end users ensures that their already large share of the messaging
+   market will continue to exist for some time. Thus it is also
+   essential that strategies that allow these systems to be 'seamlessly'
+   integrated within the global messaging community are put in place.
+   Not least due to the indications that the main messaging vendors are
+   developing X.400(1988) and RFC 822/MIME gateways, a strategy to link
+   these systems together via X.400(1988) and RFC 822/MIME should be
+   developed.
+
+
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 24]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+   To make migration to a X.400(1988) service feasible, extensive
+   migration and coexistence options for various non-X.400(1988) users
+   have to be developed. Main issue in each migration strategy remains
+   the co-operation of the users. The migration needs to be user-driven,
+   i.e., the users need to be convinced of the added functionality
+   (versus the cost) of migrating towards X.400(1988). A detailed
+   summary of the different issues and possible problems involved in the
+   transition to a X.400(1988) based messaging service, with respect to
+   what are commonly accepted as the four most important messaging
+   services: RFC 822, MIME and PEM; X.400(1984); MAIL-11 and PC LAN
+   messaging systems are presented in this chapter.
+
+6.1. PC LAN E-mail systems
+
+   To provide coexistence and migration the usage of gateways is
+   unavoidable. The quality of these gateways, with regard to:
+
+      - Transparency (gatewaying multimedia messages, transparent
+        addressing)
+      - Manageability
+      - Reliability
+
+   has to be improved. Ultimately through usage of APIs like MAPI and
+   CMC, the users interface hopefully will become independent of the
+   mail protocol that is used. It will then be expected to be possible
+   to let the user retain his preferred mail user interface, while the
+   protocol used migrates to X.400(1988).
+
+   Via the use of these APIs it may be possible to access the full
+   features of X.400(1988) while retaining a proprietary PC LAN UAs.
+   This way a PC LAN can be easily connected to a X.400(1988) backbone.
+   This usage of APIs to ease migration for end users should be
+   encouraged.
+
+   The migration of PC LAN E-mail systems will likely be driven by the
+   commercial vendors of mail enabled applications, such as UAs, Work
+   Group Systems, Task Flow Systems plus X.400(1988) MTAs and gateways
+   able to serve these applications via these new APIs.
+
+6.2. RFC 822, MIME and PEM services
+
+   A migration from RFC 822 / MIME and PEM services to X.400(1988) needs
+   to be formulated for those management domains that wish to effect
+   this change. As well a long term transition and coexistence phase
+   needs to be accommodated due to the existing base of RFC 822 users.
+   An understanding of the issues involved in migrating from RFC 822 to
+   X.400(1988) messaging services is essential before any rational
+   decisions on migration can occur.  Certainly one, if not the main,
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 25]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+   issue in such a migration is that the migration must allow a
+   transition period where maximum functionality between both services
+   exists. Any migration must be aware that RFC 822 messaging services
+   are a 'moving target'.
+
+    - Ease of transition as perceived by an RFC 822 user mandates
+      that the user's existing mail folders are converted into the
+      new mail product's folder system flawlessly.
+
+    - The RFC 822's user's e-mail address should remain the same
+      even after a migration. (i.e., the user keeps the same address
+      that has two different notation forms: X.400 and RFC 822).
+
+    - Users contemplating a migration will be stimulated to do so
+      if they experience no loss of service as regards MIME and
+      X.400(1988) gatewaying; are still able to insert RFC 822
+      style addresses into the X.400(1988) UA and are provided with
+      high performance X.400-to-RFC 822 gateways.
+
+    - The added connectivity provided by X.400(1984 or 1988)
+      gateways to fax, telex, post etc. plus additional X.400 users
+      that the user is able to reach easily (whilst not losing
+      connectivity to RFC 822 addresses) plus the additional
+      functionality of X.400(1988) possible when communicating with
+      X.400(1988) users will also act as a stimulant to a
+      migration.
+
+    - The functionality provided by RFC 822 / MIME products will
+      be the yardstick that an RFC 822 user compares an offered
+      X.400(1988) product with. As such X.400(1988) products must
+      provide some basic and important functions like: Character
+      Set support via GeneralText; Multimedia capability via
+      Extended Body Parts; low message delays within the seconds
+      time scales and ease of configuration of products. At present
+      there is no RFC 822 equivalent to X.400 delivery and receipt
+      notifications and as such these functions are seen as extra
+      functionality by the user.
+
+    - A follow on to the extra functionality point above is that
+      present RFC 822 users, most likely commercial users, that
+      want to be able to use EDI or other mail enabled applications
+      that need security, message audits and positive confirmations
+      will be encouraged to migrate to X.400(1988). A decision to
+      use X.400(1988) in this case would be especially attractive
+      for those commercial RFC 822 users that are already operating
+      multiple lower layer networks. As X.400(1988) accommodates
+      multiple different network layers easily, the cost to migrate
+      could be considered quite small.
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 26]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+6.3. X.400(1984) services
+
+   A number of problems can be identified in a migration from
+   X.400(1984) to X.400(1988). They are summarised as,
+
+    - OSI supporting layers are mandatory in the ISO10021 MOTIS
+      standard, while the support of the complete OSI stack (normal
+      mode ) is optional in the otherwise equivalent CCITT
+      X.400(1988) specifications. It is thus recommended that the
+      migration from X.400(1984) should be straight to ISO 10021
+      i.e., straight to use of the full OSI stack with normal mode
+      RTS.
+
+    - There is a negative impact on quality of service caused by
+      implementation decisions related to the 'General Extension
+      Mechanism'. To overcome this negative impact no minimal
+      X.400(1988) MTAs, which relay the syntax but understand none
+      of the semantics of extensions, should be used.
+
+    - All X.400(1988) MTAs should generate reports containing the
+      extensions that are present in the original message and route
+      such reports through the DL expansion hierarchy where
+      appropriate.
+
+    - Choice of standards to be used within mixed X.400(1984 and
+      1988) management domains needs to accommodate in one option
+      the danger of undetectable routing loops from incorrectly
+      configured routing entries and in another option the problem
+      that systems that have fixed the routing loop problem may not
+      all be consistently implemented due to ambiguities within the
+      standards. The choice of which of these two options a
+      management domain uses internally has no impact on external
+      management domains.
+
+    - DDA support is needed by X.400(1984) systems to address
+      X.400(1988) Common Name Attribute users [2].
+
+    - Minimum loss of service quality mandates that downgrading of
+      X.400(1988) body parts to X.400(1984) bodyparts be done
+      according to the MIMEMHS specifications [4].
+
+    - To enhance connectivity to both X.400(1984 and 1988)
+      management domains without degradation of X.400(1988)
+      service, management domain entry points that support both
+      X.400(1984 and 1988) are recommended.
+
+
+
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 27]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+    - Ensuring that no X.400(1988) MTAs transit via X.400(1984)
+      MTAs. This allows no degradation of X.400(1988) service
+      quality [17].
+
+   The consequence of the last point is that the existing European
+   Research X.400(1984) - formerly COSINE MHS - MTA RELAY backbone
+   should be one of the first MTA communities to migrate to X.400(1988).
+
+6.4. Mail-11 services
+
+   The Mail-11 (also known as DECnet mail) e-mail service is the major
+   e-mail service used within the High Energy Physics and Space Physics
+   Analysis Networks (i.e., HEPnet and SPAN) and is the native e-mail
+   service present on VMS operating systems. The Mail-11 service is
+   considered the most popular service by the large HEPnet / SPAN
+   community. Mail-11 provides also large and easy to use gateways to
+   other E-mail protocols, like X.400 (84), RFC 822 (SMTP over TCP/IP,
+   DECnet and X.25, BSMTP over NJE), and PC LAN E-mail services.
+
+   Jointly with the "old style" Mail-11 UA, the DECnet Phase V (OSI
+   CLNS) service provides the native capability to run X.400 (88) and
+   X.400(1984) services. There is thus the potential for X.400 (88)
+   services to become available as soon as the HEPnet / SPAN community
+   migrates to DECnet Phase V. However the availability of VMS based UAs
+   for the X.400(1988) service is still very limited and is thus forcing
+   users to continue to stay with their Mail-11 UA (and thus the Mail-11
+   service).
+
+   Users in HEPnet / SPAN are demanding enhancements to their mail
+   services to support multimedia and delivery / read receipt services.
+   This is a strong driving factor for good X.400(1988) UAs to become
+   available soon to allow users to properly use the available
+   X.400(1988) service of DECnet Phase V.
+
+7.  Benefits of migrating to X.400(1988) and the involved costs
+
+   The actual as compared to the potential benefits of migrating from
+   one's existing mail system to a new mail protocol is very dependent
+   on good products, good organisation of the migration and a degree of
+   commitment that the transition is worth the cost. Quantifiable and
+   accurate cost / benefit ratios for such a migration are not possible
+   within the decentralised European R&D environment and as such are not
+   generated.
+
+   We have in this chapter listed the benefits that such a migration to
+   X.400(1988) achieves. We have also given an indication of the
+   relative costs of such a migration. Provided that there are good
+   products, and taken in conjunction with the recommendations of
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 28]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+   Chapter 8 and Appendices A and B, the task force is confident that
+   these potential benefits will translate into actual benefits and be
+   worth the costs incurred.
+
+*Benefits*
+
+   Below is a list of non-technically oriented benefits and the features
+   of X.400(1988) that enable these benefits to occur. The benefit of,
+
+    - efficient and innovative communication within Europe is
+      assisted by establishing an X.400(1988) messaging service
+      that integrates European industry, government and academia;
+
+    - an increase in business efficiency by the use of EDI (for
+      example automatic processing of business forms, exchange of
+      business contracts, etc.) is enhanced by the security aspects
+      of X.400(1988) i.e., non-repudiation, authentication,
+      confidentiality, integrity plus secure access between MHS
+      components.
+
+    - allowing European users to communicate in their native
+      European languages is brought about by the GeneralText body
+      part of X.400(1988).
+
+    - remote users and Small and Medium size Enterprises(SME)
+      using e-mail for electronic commerce is encouraged by
+      reducing the entry level costs for use of e-mail. An SME's
+      use of Remote UAs in conjunction with a service provider's MS
+      -instead of purchasing their own MTA - is accommodated by
+      X.400(1988).
+
+    - providing global messaging for all e-mail users, but
+      recognising the existing market realities of heterogeneous e-
+      mail systems, would be enhanced by the establishment of
+      gateways to X.400(1988).
+
+    - being able to recover costs by charging and accounting for
+      messaging services back to users - this is especially
+      important for commercial service providers - is brought about
+      by the message auditing capabilities of X.400(1988).
+
+    - communication with users that have no access to E-mail (for
+      example if such users are defined within Distribution Lists)
+      is enhanced by X.400(1988)'s support for gateways to physical
+      delivery, fax, telex, teletex, etc.
+
+
+
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 29]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+    - building upon the existing X.400(1984) infrastructure (i.e.,
+      reduction of establishment costs) is brought about by
+      migrating the X.400(1984) infrastructure to X.400(1988).
+
+    - a reduction in manpower (and thus costs) to manage a global
+      messaging service is brought about by the messaging service's
+      ability to utilise the global distributed directory for
+      management information.
+
+    - the messaging infrastructure to meet new user requirements
+      is enhanced by the support for General Extensible Mechanism.
+
+    - making E-mail more user friendly is brought about by a
+      messaging service that allows the use of the more natural
+      directory names in E-mail addresses.
+
+    - increased effectiveness of messaging by the use of DLs is
+      brought about by X.400(1988)'s support of powerful nesting
+      capabilities and management for DLs.
+
+    - an increase in global message delivery performance and
+      reliability is enhanced by the ability of X.400(1988) to use
+      X.500 for MTA routing.
+
+    - more messages being successfully delivered to mobile or
+      transient users is enhanced by the provision of the Message
+      Store.
+
+    - multimedia use is enhanced by the ability to define new body
+      parts and to support multiple types of binary data such as
+      audio and video.
+
+    - establishing optimum and seamless conversion of messages
+      based upon the capabilities of a user is brought about by the
+      ability of X.400(1988) to act upon UA capabilities.
+
+*Costs*
+
+   The generic costs to establish an X.400(1988) pilot service can be
+   broken down into:
+
+       - a cost per backbone of RELAY MTAs (as used by the European
+         research community - the former Cosine MHS service),
+       - a cost per service provider,
+       - a cost per organisation,
+       - a cost per user and
+       - a cost per user MTA for migrating to X.400(1988).
+
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 30]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+   To bring about the benefits, mentioned above, certain costs will be
+   incurred and they are summarised below:
+
+   - Cost per backbone of RELAY MTAs (as used by the European
+     research community - the former Cosine MHS service)
+
+         - The equipment costs of migrating backbone RELAY MTAs.
+
+         - The establishment of some sort of organisational /
+           project group to oversee a backbone RELAY MTA pilot.
+
+      As most of the RELAY MTAs are already X.400(1988) capable, there
+      is already a MHS Co-ordination service in place that could be used
+      for this function and the number of backbone RELAY MTAs is less
+      than 100 in number the cost for migrating the RELAY MTA backbone
+      is considered relatively low.
+
+   - Cost per service provider
+
+         - If the RELAY MTA backbone (formerly Cosine MHS) is
+           migrated towards X.400(1988), then the remaining cost
+           for a service provider for migrating the infrastructure
+           towards X.400(1988) is relatively low.
+
+         - The operational costs for organisational issues, for
+           example dealing with OID registrations, is low if
+           national R&D service providers act as a clearinghouse
+           for their own national R&D institutions e.g.,
+           Universities.
+
+   - Cost per organisation, end user and MTA
+
+         - The operational costs of migrating end users and their
+           MTAs in management domains to X.400(1988) are higher
+           than the costs involved with migrating the
+           infrastructure. This is due to the order of at least 10
+           to 100 times more MTAs, as compared to the service
+           providers, that would be involved with a migration to
+           X.400(1988). As the infrastructure needs to migrate
+           first, the costs for the end user MTAs can be reduced
+           by profiting from the migration experience of the
+           service providers.
+
+         - The education and training costs for users and system
+           managers are significant, due to the amount of end
+           users and end user MTAs. Any marginal cost savings per
+           user which can be made, e.g., by deployment of automated
+           tools, should be considered due to the large overall
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 31]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+           savings that accrue.
+
+         - The costs of any potential disruption of the end user's
+           messaging service are high - due to the huge numbers of
+           end users involved - and as such only a very well
+           managed, phased and planned migration should be
+           considered.
+
+   - Software costs
+
+         - The costs for software development are outside the
+           scope of this report. However it is clear that cost
+           needs to be incurred in order to provide software that
+           is easy to install and use. As a result of the work of
+           the task force a list of possibly needed components and
+           likely changes to existing components can be proposed,
+
+                Modifications, but not new developments, to
+                  software for:
+
+                     - X.400(1988) MTAs, X.400(1988) UAs, DSAs,
+                       DUAs and MSs.
+
+                New software developments for:
+
+                     - MIME to MHS Gateways, X.400(1988) network
+                       management, mailbox conversion, PC LAN
+                       directory synchronisation, PC LAN gateways
+                       and UA capability registration.
+
+         - The distribution costs for any new software (for the
+           European R&D community) are low if usual academic
+           distribution methods - FTP servers, E-mail Based
+           servers, Gopher, World Wide Web and Archie - are used.
+
+*Summary*
+
+   Migration towards a X.400(1988) service needs to evolve from the
+   inside (the messaging backbone) outward (to the end user MTAs and end
+   users themselves). Due to the numbers involved both the costs and the
+   benefits associated with the migration increase as the migration
+   evolves towards the end users.
+
+   The benefits of migrating to a X.400(1988) service are a feature rich
+   well defined open standard with high functionality , scalability, use
+   of directory, multimedia and secure messaging capability. The costs
+   for migrating a RELAY MTA backbone can be considered relatively low
+   whilst the migration of end user MTAs and the migration of the end
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 32]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+   users themselves are relatively high. These costs should of course be
+   balanced against the cost of a disrupted service that one might get
+   if no migration occurs at all and the current service (e.g.,
+   X.400(1984)) reaches the limits of its scalability and/or
+   functionality.
+
+   It is important to realise that if end users themselves do not
+   experience direct feedback of the benefits from X.400(1988), this may
+   make the organisational motivation needed to effect such a migration
+   difficult to achieve. In effect, the establishment of a pilot
+   X.400(1988) service is and should be driven by the requirements of
+   end users and thus achieving end user benefits - as listed above -
+   must be given a higher priority within a X.400(1988) service than
+   solely the extra service provider benefits.
+
+8.  Main Recommendations
+
+   The RARE WG-MSG Task Force on 'The Establishment of an X.400(1988)
+   Pan European Pilot Messaging Service' has identified a number of high
+   level recommendations for establishing such a
+    service. The main high level recommendations are listed within this
+   chapter. A more detailed elaboration of these main recommendations is
+   given in Appendix A. Appendix A is provided for policy makers wishing
+   more background on the main recommendations. As well, a list of very
+   detailed guidelines, plus some issues requiring further
+   investigation, is given in Appendix B. Appendix B will be especially
+   useful for personnel seeking detailed technical guidelines which are
+   consistent with the main high level recommendations.
+
+*Recommendations*
+
+    - Establish a X.400(1988) pilot service encompassing European
+      Commercial, Government and Academic bodies. Such a pilot
+      service to be co-ordinated by using an industry forum where
+      all parties could meet. The use of an existing forum, where
+      user organisations are well represented, is desirable if
+      commercial end users organisation's requirements are to be
+      met. The forum should also be open to non-European
+      participants.
+
+    - X.400(1988) end user services should be provided as well as
+      a X.400(1988) backbone RELAY MTA service within a X.400(1988)
+      pilot service. The end user services should be given a high
+      priority.
+
+    - Help an already emerging market place in X.400(1988)
+      products to prosper by ensuring that a suitable supply of
+      high quality X.400(1988) public domain software is available.
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 33]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+      The Internet has proven, that public domain software, free of
+      any commercial restrictions, is further rapidly developed, by
+      Small and Medium Size Enterprises (SMEs), into derivative
+      products suitable for the commercial market.
+
+    - Any pilot service should be well co-ordinated and result
+      driven but utilise a distributed market oriented approach. It
+      is considered very difficult to organise and plan such a
+      pilot under the assumption of a single centrally funded body
+      i.e., driven from the 'top'. A more 'market driven' or
+      distributed organisation is considered feasible, and likely
+      to succeed, if all the market 'players' are fully involved
+      i.e., a 'bottom' up approach.
+
+    - For the academic community - and ever more for the
+      commercial community - there is a business need to ensure near
+      total and 'perfect' integration with the existing and also
+      evolving RFC 822 based services.
+
+    - For the academic community a rapid migration of the existing
+      X.400(1984) backbone RELAY MTAs, used within the European R&D
+      X.400(1984) service, - formerly the COSINE MHS service - is
+      considered urgent. This migration will provide a 'bootstrap'
+      path for academic organisations to internationally pilot
+      X.400(1988) services. Such end user piloting is not
+      considered feasible if X.400(1984) backbone RELAY MTAs are
+      used for an X.400(1988) service (see Reference [17] for
+      technical details).
+
+   The report does not include any recommendations on development and
+   deployment of RFC 822 / MIME / PEM related (pilot) services, as these
+   are outside of the scope of the Task Force. However, since both
+   X.400(1988) and RFC 822 / MIME / PEM will be developed and used
+   within the European R&D community, such a pilot should also be
+   considered.
+
+9.  Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 34]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+10. Reading List and Bibliography
+
+   This section contains a list of relevant reference documents that can
+   be used for further reading.
+
+      [1]         Kille;, S., "Mapping between X.400(1988) / ISO 10021
+                  and RFC 822", RFC 1327/RTR 2, University College
+                  London, May 1992.
+
+      [2]         Kille, S., "X.400 1988 to 1984 downgrading",
+                  RFC 1328/RTR 3, University College London, May 1992.
+
+      [3]         Adie, C.,  "A Survey on Multimedia Projects, Products
+                  and Standards", RTR 5, Edinburgh University Computing
+                  Centre, January 1993.
+
+      [4]         Alvestrand, H., and S. Thompson, "Equivalences between
+                  1988 X.400 and RFC 822 Message Bodies", RFC 1494,
+                  SINTEF DELAB, Soft*Switch Inc., August 1993.
+
+      [5]         Alvestrand, H.,  Kille, S., Miles, R., Rose, M.,
+                  and S. Thompson, "Mapping between X.400 and RFC 822
+                  Message Bodies", RFC 1495, SINTEF DELAB, ISODE
+                  Consortium, Soft*Switch, Inc., Dover Beach
+                  Consulting, Inc., Soft*Switch, Inc., August 1993.
+
+      [6]         Alvestrand, H., Romaguera,  J., and K. Jordan,
+                  "Rules for downgrading messages from X.400/88 to
+                  X.400/84 when MIME content-types are present in the
+                  messages", RFC 1496, SINTEF DELAB, NetConsult AG,
+                  Control Data Systems, Inc., August 1993.
+
+      [7]         IETF MHS-DS Working Group, Works in Progress.
+
+      [8]         Borenstein, N., and N. Freed, "MIME (Multipurpose
+                  Internet Mail Extensions) Part One: Mechanisms for
+                  Specifying and Describing the Format of Internet
+                  Message Bodies", RFC 1521, Bellcore, Innosoft,
+                  September 1993.
+
+      [9]         Moore, K., "MIME (Multipurpose Internet Mail
+                  Extensions) Part Two: Message Header Extensions for
+                  Non-ASCII Text", RFC 1522, University of Tennessee,
+                  September 1993.
+
+
+
+
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 35]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+      [10]        Kaliski, B., "Privacy Enhancement for Internet
+                  Electronic Mail: Part IV: Key Certification and
+                  Related Services", RFC 1424, RSA Laboratories,
+                  February 1993.
+
+      [11]        Balenson, D., "Privacy Enhancement for Internet
+                  Electronic Mail: Part III: Algorithms, Modes, and
+                  Identifiers", RFC 1423, TIS, February 1993.
+
+      [12]        Kent, S., "Privacy Enhancement for Internet
+                  Electronic Mail: Part II: Certificate Based Key
+                  Management", RFC 1422, BBN, February 1993.
+
+      [13]        Linn, J., "Privacy Enhancement for Internet
+                  Electronic Mail: Part I: Message Encryption and
+                  Authentication Procedures", RFC 1421, IAB IRTF PSRG,
+                  IETF PEM WG, February 1993.
+
+      [14]        Jurg, P., and E. Huizer, "The SURFnet electronic mail
+                  project", SURFnet, EH/PJ932307, July 1993.
+
+      [15]        Alvestrand, H., "X.400 Use of Extended Character
+                  Sets", RFC 1502/RTR 7, SINTEF DELAB, August 1993.
+
+      [16]        Manros, C.-U., "The X.400 Blue Book Companion", ISBN
+                  1 871802 00 8, Technology Appraisals Ltd, 1989.
+
+      [17]        Houttuin, J., and J. Craigie, "Migrating from
+                  X.400(1984) to X.400(1988)", RFC 1615/RTR 9,
+                  RARE, JNT, May 1994.
+
+      [18]        Nagelhus, I. et al., "Survey of E-mail systems with
+                  X.400 capability".
+
+      [19]        "A White Paper on X.400(1988)", EMA Report.
+
+      [20]        IAB, IESG, "The Internet Standards Process --
+                  Revision 2", RFC 1602, March 1994.
+
+
+
+
+
+
+
+
+
+
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 36]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+11. Terminology
+
+      ADMD     Administration Management Domain
+      ASCII    American Standard Code for Information Exchange
+      ASN.1    Abstract Syntax Notation One
+      AU       Access Unit
+      CCITT    Comite Consultatif International de Telegraphique et
+               Telephonique
+      CEN      Comite Europeen de Normalisation
+      CENELEC  Comite Europeen de Normalisation Electrotechnique
+      CEPT     Conference Europeene des Postes et Telecommunications
+      CONS     Connection Oriented Network Service
+      COSINE   Co-operation for OSI networking in Europe
+      DL       Distribution List
+      DIS      Draft International Standard
+      EMA      Electronic Messaging Association
+      EN       European Norm
+      ENV      Draft EN, European functional standard
+      IEC      International Electrotechnical Commission
+      IETF     Internet Engineering Task Force [20]
+      IPM      Inter-Personal Message
+      IPMS     Inter-Personal Messaging Service
+      IPN      Inter-Personal Notification
+      ISO      International Organisation for Standardisation
+      JNT      Joint Network Team (UK)
+      JTC      Joint Technical Committee (ISO/IEC)
+      MD       Management Domain (either an ADMD or a PRMD)
+      MHS      Message Handling System
+      MHS-DS   Message Handling Systems use of Directory Service
+               Working Group from the IETF
+      MIME     Multi-purpose Internet Mail Extensions (extensions to
+               RFC 822) [6]
+      MOTIS    Message-Oriented Text Interchange Systems
+      MTA      Message Transfer Agent
+      MTL      Message Transfer Layer
+      MTS      Message Transfer System
+      NBS      National Bureau of Standardization
+      OSI      Open Systems Interconnection
+      PEM      Privacy Enhanced Mail [10]
+      PRMD     Private Management Domain
+      RARE     Reseaux Associes pour la Recherche Europeenne
+      RFC      Request For Comments (series of Internet publications)
+      RFC 822  RFC describing Internet Message format for Electronic
+               mail
+      RTR      RARE Technical Report (series of RARE publications)
+      RTS      Reliable Transfer Service
+      WG-MSG   RARE Working Group on Mail and Messaging
+
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 37]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+Appendix A - Elaboration on the main recommendations
+
+   The main recommendations of the report are elaborated upon in more
+   detail within this appendix.
+
+    - In order to provide a globally pervasive messaging service,
+      it is recommended to establish a well operated Pan-European
+      X.400(1988) pilot backbone comprising MTAs and MSs,
+      connecting partners within Industry, Commercial Service
+      Providers, Academia and Public Bodies (CEC, National
+      Governments, etc.). The pilot should be open to global
+      participation.
+
+    - In order to maintain the widest connectivity with the
+      highest possible functionality, gateways should be installed
+      that gateway between X.400(1988) and RFC 822/MIME. These
+      gateways should follow the specifications of RFC 1327 [1] and
+      RFC 1494 et al. [4]. Experience with these gateways should be
+      fed back into the appropriate RARE and IETF Working Groups to
+      improve the standards.
+
+    - In order that the 'business needs' of non-R&D organisations
+      can be inserted at an early stage into the goals of the pilot
+      and ensuring that the success of the pilot in meeting these
+      goals can be measured and disseminated i.e., to encourage the
+      active participation of non-R&D organisations within the
+      pilot, it is recommended that an open forum comprising
+      industry, service providers, public bodies and academia
+      should be used. Preferably an existing forum where end users
+      are heavily involved is desirable.
+
+    - In order for meaningful co-operation between bodies affected
+      by the pilot to occur and thus hopefully reducing unnecessary
+      duplications, it is recommended that there are close liaisons
+      and contacts between at least the IETF, RARE, EARN, EUnet,
+      RIPE, Y-NET, EEMA, EMA, EWOS, OIW, CEN/CENELEC, ISO, CCITT,
+      CEC and European governmental bodies and those involved
+      within the pilot. The suggested mechanism for a meaningful
+      liaison is that enough participants of the above
+      organisations attend the common forum mentioned above. It is
+      also suggested that as much as possible e-mail distribution
+      lists be used to communicate between forum participants.
+
+    - In order that the pilot have measurable results, it is
+      recommended that the pilot shall be implemented in phases. It
+      is considered that at least two phases are needed:
+
+
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 38]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+         - phase 1 - initial short start up phase with a small
+           number of participants. The result of this phase is
+           that any needed procedures, co-ordination mechanisms,
+           etc. are put into place for the large scale piloting of
+           phase 2.
+
+         - phase 2 - phase with a wide Pan-European participation.
+           The result of this phase should be a proof of scaling
+           of the pilot X.400(1988) service i.e., the goals of the
+           pilot as defined in Chapter 1 are met. It is expected
+           that upon successful completion of this phase a natural
+           evolution to a global deployment of a X.400(1988)
+           service will have started.
+
+    - In order to rapidly complete phase 1 of the pilot and that
+      the pilot is at least Pan-European in scope, it is
+      recommended that; a number of R&D service providers, one each
+      from several European countries; at least 2 North American
+      R&D service providers; at least 1 Japanese R&D service
+      provider and a small number of commercial service providers
+      and commercial organisations are actively involved in phase
+      1.
+
+    - In order to stimulate the creation of an economically viable
+      market place for X.400(1988) products (i.e., MTAs, UAs, etc.)
+      (i.e., users are willing to purchase such products), it is
+      recommended that a suitable minimum number of new software
+      implementations and or modifications to existing software
+      implementations be funded. The resulting software to be
+      inserted into the Public Domain free of any financial
+      restrictions on further commercial exploitation. By using
+      this mechanism, Small and Medium Size Enterprises (SMEs) will
+      be encouraged to commercially exploit such products.
+
+    - Due to the strong influence of the R&D community within the
+      pilot plus the desire to produce standardised products
+      quickly and pragmatically, it is recommended that any
+      standards proposed within the scope of an X.400(1988) pilot
+      (for example standards re: character sets and body parts
+      gatewayed to and from X.400(1988) and RFC 822 / MIME) are
+      conformant to and candidates for Internet standardisation. As
+      a concrete example of the standardisation process, this means
+      that at least two independent software implementations, for
+      each product category, (of which one product preferably in
+      the Public Domain) must be proven as interworking to a
+      proposed standard before the proposed standard can be
+      elevated to draft standard [20].
+
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 39]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+    - To ensure that there is a market driven demand for
+      X.400(1988) products within the commercial market place, it
+      is recommended that the maximum number of Public Domain
+      implementations that are funded, by any one public funding
+      organisation, is two. It is desirable that at least one other
+      product, preferably commercially based and not within the
+      Public Domain, is produced.
+
+    - In order that any necessary information required for the
+      effective operation of the X.400(1988) pilot, including not
+      least OID assignments, mapping rules, information about
+      interconnection partners, naming authority information be
+      made widely available, it is recommended that an
+      electronically accessible information base be established.
+
+    - In order that any necessary organisational issues needed for
+      a deployment of an X.400(1988) service have a body in place
+      to deal with this issue, it is recommended that the pilot
+      either identify and list which bodies are responsible for
+      which issues or else actively ensure that a suitable body is
+      being put in place.
+
+Appendix B - A number of detailed guidelines.
+
+   The Task Force has the following detailed guidelines:
+
+*Product and operational service guidelines*
+
+    - To ensure that there is no degradation of X.400(1988)
+      service between X.400(1988) originators and destinations, the
+      topology of the MTS must be such that no X.400(1984) MTA acts
+      as a relay between any two X.400(1988) users.
+
+    - As the existing R&D X.400(1984) service (formerly COSINE
+      MHS) now comprises a large number of X.400(1988) capable
+      RELAYs, it would be relatively straight forward that the
+      existing COSINE MHS RELAYs be one of the first communities
+      that are migrated to X.400(1988) capabilities. This would
+      ensure that X.400(1988) MTAs using the RELAY backbone
+      experience no loss of service.
+
+    - To be able to operate an X.400(1988) service a properly
+      operated X.400(1988) infrastructure should be established,
+      consisting of X.400(1988) MTAs, X.400(1988) MTAs with
+      downgrading capabilities according to RTR 3, Message Store
+      services and gateways to RFC 822 based upon RTR 2 and
+      extended gatewaying functionality for multimedia mail.
+
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 40]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+    - To ensure maximum use of the OSI supporting layers plus
+      support of normal mode RTS, it is recommended that a
+      migration to ISO 10021 is effected i.e., straight to use of
+      the full OSI stack with normal mode RTS.
+
+    - To ensure maximum quality of service as impacted by
+      implementation decisions related to the 'General Extension
+      Mechanism', it is recommended that no minimal X.400(1988)
+      MTAs, which relay the syntax but understand none of the
+      semantics of extensions, should be used.
+
+    - It is recommended that all X.400(1988) MTAs should generate
+      reports containing extensions copied from the subject message
+      and route reports through the DL expansion hierarchy where
+      appropriate.
+
+    - It is recommended that all X.400(1984) UAs are able to
+      generate and display DDAs. This will allow such systems to
+      address X.400(1988) Common Name Attribute users.
+
+    - To enhance connectivity to both X.400(1984 and 1988)
+      management domains without degradation of X.400(1988)
+      service, management domain entry points that support both
+      X.400(1984 and 1988) are recommended.
+
+    - To ensure total connectivity between RFC 822 domains
+      migrating to X.400(1988), it is recommended that a local
+      X.400-to-RFC-822 gateway is made operational or a reliable
+      service agreement for the external provision of such a
+      gateway is effected before any migration begins.
+
+*Migration utilities needed*
+
+    - It is considered very helpful if conversion utilities that
+      allow a flawless conversion of an RFC 822 user's existing
+      mail folders to a X.400(1988) product's folder system be
+      implemented. However further investigation is needed before
+      recommending that such tools be made a mandatory part of any
+      funded software development.
+
+    - It is recommended that the ease of configuration of
+      X.400(1988) products is made as automatic as possible.
+      Consideration should be given to a) modern user interfaces b)
+      automatic processing of 'old RFC 822' configuration files
+      into the 'new X.400(1988)' configuration files i.e., a reuse
+      of the user's previous options and configurations should be
+      the result. If a 'simple' configuration interface is needed
+      it should be as compatible as possible with the present RFC
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 41]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+      822 mailer's i.e., this concretely means editing of ASCII
+      files.
+
+*Issues for further study*
+
+   The pilot X.400(1988) messaging service must ensure that the issues
+   listed below are either being investigated by an appropriate body or
+   if not initiate actions to properly address them. The issues have
+   been grouped under Products, Organisational and Deployment.
+
+    - Products
+
+         - Any X.500 DSAs, DUAs, APIs e.g., LDAP, etc. changes
+           needed to support X.400(1988) messaging.
+
+         - X.400(1988) MTAs, UAs, MSs, gateways to RFC 822/MIME
+           and X.400(1984) plus gateways to other messaging
+           systems e.g., Microsoft Mail, Lotus cc:Mail, etc.
+
+         - User Interfaces that integrate X.400(1988) UAs and
+           X.500 DUAs with user applications such as Word
+           Processors, etc.
+
+         - E-mail network management software both for users and
+           administrators
+
+    - Organisational
+
+         - trusted network for security (i.e., the distribution of
+           security keys) and whether this trusted network should
+           or can be the same as the PEM trusted network presently
+           under deployment.
+
+         - usage of PEM within X.400(1988).
+
+         - PEM to and from X.400(1988) gatewaying.
+
+         - how to register and publicise object IDs for
+           X.400(1988).
+
+         - addresses are well publicised of PRMD and ADMD
+           registration authorities.
+
+         - creation and modification authority for X.400-to-RFC-
+           822 mapping rules is defined.
+
+         - creation and modification authority for MTA routing
+           rules is defined.
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 42]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+
+         - what methods should be used to liaison to other bodies
+           like IETF, ISO, EEMA, EMA, etc.
+
+         - ensuring that any Public Domain software needed for the
+           X.400(1988) service is distributed widely, quickly and
+           efficiently.
+
+    - Deployment
+
+         - which services should start such a migration (i.e.,
+           COSINE MHS RELAYs, Universities, other).
+
+         - the topology of the X.400(1988) MTS.
+
+         - addressing of users between X.400(1984 and 1988) and
+           RFC 822 e.g., how will X.400(1988) T.61 address
+           components be processed by X.400(1984) and RFC 822
+           systems.
+
+         - which X.400(1988) body parts MUST be supported by the
+           research community.
+
+         - if any new APIs - or modified APIs - are needed for
+           X.400(1988) and messaging in general.
+
+         - the specifications and development of any needed Public
+           Domain software.
+
+         - what existing Public Domain software should be modified
+           to accommodate X.400(1988) systems.
+
+         - how rapidly to deploy the X.400(1988) service.
+
+         - ensuring that there is 'little or no loss of service'
+           in any migration from X.400(1984), or RFC 822, to
+           X.400(1988).
+
+         - considering what Value Added Services, based upon
+           X.400(1988), could be started to encourage uptake of
+           X.400(1988).
+
+
+
+
+
+
+
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 43]
+
+RFC 1616     X.400(88) for European Academics and Research      May 1994
+
+
+Authors' Addresses
+
+   Only the two editors' complete addresses are listed here:
+
+   Erik Huizer (Task Force chair)
+   SURFnet bv
+   P.O. Box 19035
+   NL-3501 DA  Utrecht
+   Europe
+
+   Phone: +31 30 310 290
+   RFC 822: huizer@surfnet.nl
+   X.400:   S=huizer;O=SURFnet;PRMD=surf;ADMD=400net;C=nl;
+
+
+   James A. (Jim) Romaguera
+   NetConsult AG
+   Berner Technopark
+   Morgenstrasse 129
+   CH-3018 Bern
+   Europe
+
+   Phone: +41 31 998 4141
+   RFC 822: romaguera@netconsult.ch
+   X.400: S=romaguera;O=netconsult;PRMD=SWITCH;ADMD=ARCOM;C=CH;
+
+   The Task Force as a whole can be reached per e-mail at the
+   address:
+
+   RFC 822: tf-88@SURFnet.nl
+   X.400:   S=tf-88;O=SURFnet;PRMD=surf;ADMD=400net;C=nl;
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+RARE WG-MSG Task Force 88                                      [Page 44]
+