rfc1616.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

      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