rfc1616.txt

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

      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