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: [email protected]
   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: [email protected]
  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: [email protected]
  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: [email protected]
  X.400:   S=tf-88;O=SURFnet;PRMD=surf;ADMD=400net;C=nl;




















RARE WG-MSG Task Force 88                                      [Page 44]


You are viewing proxied material from gopher.rbfh.de. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.