rfc1616.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,392 行 · 第 1/5 页

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-