rfc1616.txt

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

      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