rfc2156.txt

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

   additional implications, or the (non) support is not intuitive.  For
   partial support, the level of partial support is summarised.  Where
   partial support is good, this will be described by a phrase such as
   "Supported by use of.....".  A common case of this is where the
   service is mapped onto a non-standard service on the other side of
   the gateway, and this would have lead to support if it had been a
   standard service.  In many cases, this is equivalent to support.  For
   partial support, an indication of the mechanism is given, in order to
   give a feel for the level of support provided.  Note that this is not
   a replacement for Chapter 5, where the mapping is fully specified.

      If a service is described as supported, this implies:

   -    Semantic correspondence.

   -    No (significant) loss of information.

   -    Any actions required by the service element.

   An example of a service gaining full support: If an RFC 822
   originator specifies a Subject: field, this is considered to be
   supported, as an X.400 recipient will get a subject indication.

   In many cases, the required action will simply be to make the
   information available to the end user.  In other cases, actions may
   imply generating a delivery report.

   All RFC 822 services are supported or partially supported for
   origination.  The implications of non-supported X.400 services is
   described under X.400.

2.1.2.  Reception of Messages

   For reception, the list of service elements required to support this
   mapping is specified.  This is really an indication of what a
   recipient might expect to see in a message which has been remotely



Kille                       Standards Track                    [Page 14]

RFC 2156                         MIXER                      January 1998


   originated.

2.2.  RFC 822

   RFC 822 does not explicitly define service elements, as distinct from
   protocol elements.  However, all of the RFC 822 header fields, with
   the exception of trace, can be regarded as corresponding to implicit
   RFC 822 service elements.

2.2.1.  Origination in RFC 822

   A mechanism of mapping, used in several cases, is to map the RFC 822
   header into a heading extension in the IPM (InterPersonal Message).
   This can be regarded as partial support, as it makes the information
   available to any X.400 implementations which are interested in these
   services. Communities which require significant RFC 822 interworking
   are recommended to require that their X.400 User Agents are able to
   display these heading extensions.  Support for the various service
   elements (headers) is now listed.

   Date:
        Supported.

   From:
        Supported.  For messages where there is also a sender field,
        the mapping is to "Authorising Users Indication", which has
        subtly different semantics to the general RFC 822 usage of
        From:.

   Sender: Supported.

   Reply-To: Supported.

   To:  Supported.

   Cc:  Supported.

   Bcc: Supported.

   Message-Id: Supported.

   In-Reply-To:
      Supported, for a single reference.  Where multiple references are
      given, partial support is given by mapping to "Cross Referencing
      Indication".  This gives similar semantics.

   References: Supported.




Kille                       Standards Track                    [Page 15]

RFC 2156                         MIXER                      January 1998


   Keywords: Supported by use of a heading extension.

   Subject: Supported.

   Comments: Supported by use of a heading extension.

   Encrypted: Supported by use of a heading extension.

   Content-Language: Supported.

   Resent-*

      Supported by use of a heading extension.  Note that addresses in
      these fields are mapped onto text, and so are not accessible to
      the X.400 user as addresses.  In principle, fuller support would
      be possible by mapping onto a forwarded IP Message, but this is
      not suggested.

   Other Fields

      In particular X-* fields, and "illegal" fields in common usage
      (e.g., "Fruit-of-the-day:") are supported by use of heading
      extensions.

   MIME introduces a number of headings.  Support is defined in RFC
   2157.

2.2.2.  Reception by RFC 822

   This considers reception by an RFC 822 User Agent of a message
   originated in an X.400 system and transferred across a gateway.  The
   following standard services (headers) may be present in such a
   message:

   Date:

   From:

   Sender:

   Reply-To:

   To:

   Cc:

   Bcc:




Kille                       Standards Track                    [Page 16]

RFC 2156                         MIXER                      January 1998


   Message-Id:

   In-Reply-To:

   References:

   Subject:

   Content-Type: (See RFC 2157)

   Content-Transfer-Encoding: (See RFC 2157)

   MIME-Version: (See RFC 2157)

   The following services (headers) may be present in the header of a
   message. These are defined in more detail in Chapter 5 (5.3.4, 5.3.6,
   5.3.7):

   Autoforwarded:

   Autosubmitted:

   X400-Content-Identifier:

   Content-Language:

   Conversion:

   Conversion-With-Loss:

   Delivery-Date:

   Discarded-X400-IPMS-Extensions:

   Discarded-X400-MTS-Extensions:

   DL-Expansion-History:

   Deferred-Delivery:

   Expires:

   Importance:

   Incomplete-Copy:

   Latest-Delivery-Time:




Kille                       Standards Track                    [Page 17]

RFC 2156                         MIXER                      January 1998


   Message-Type:

   Original-Encoded-Information-Types:

   Originator-Return-Address:

   Priority:

   Reply-By:

   Sensitivity:

   Supersedes:

   X400-Content-Type:

   X400-MTS-Identifier:

   X400-Originator:

   X400-Received:

   X400-Recipients:

2.3.  X.400

2.3.1.  Origination in X.400

   When mapping services from X.400 to RFC 822 which are not supported
   by RFC 822, new RFC 822 headers are defined, and registered by
   publication in this standard. It is intended that co-operating RFC
   822 systems may also use them.  Where these new fields are used, and
   no system action is implied, the service can be regarded as being
   partially supported.  Chapter 5 describes how to map X.400 services
   onto these new headers.  Other elements are provided, in part, by the
   gateway as they cannot be provided by RFC 822.

   Some service elements are marked N/A (not applicable).  There are
   five cases, which are marked with different comments:

   N/A (local)
      These elements are only applicable to User Agent / Message
      Transfer Agent interaction and so they cannot apply to RFC 822
      recipients.







Kille                       Standards Track                    [Page 18]

RFC 2156                         MIXER                      January 1998


   N/A (PDAU)
      These service elements are only applicable where the recipient is
      reached by use of a Physical Delivery Access Unit (PDAU), and so
      do not need to be mapped by the gateway.

   N/A (reception)
      These services  are only applicable for reception.

   N/A (prior)
      If requested, this service shall be performed prior to the
      gateway.

   N/A (MS)
      These services are only applicable to Message Store (i.e., a local
      service).

   Finally, some service elements are not supported.  In particular, the
   new security services are not mapped onto RFC 822.  Unless otherwise
   indicated, the behaviour of service elements marked as not supported
   will depend on the criticality marking supplied by the user.  If the
   element is marked as critical for transfer or delivery, a non-
   delivery notification will be generated.  Otherwise, the service
   request will be ignored.

2.3.1.1.  Basic Interpersonal Messaging Service

   These are the mandatory IPM services as listed in Section 19.8 of
   X.400 / ISO/IEC 10021-1, listed here in the order given. Section 19.8
   has cross references to short definitions of each service.

   Access management
      N/A (local).

   Content Type Indication
      Supported by a new RFC 822 header (X400-Content-Type:).

   Converted Indication
      Supported by a new RFC 822 header (X400-Received:).

   Delivery Time Stamp Indication
      N/A (reception).

   IP Message Identification
      Supported.

   Message Identification
      Supported, by use of a new RFC 822 header (X400-MTS-Identifier).
      This new header is required, as X.400 has two message-ids whereas



Kille                       Standards Track                    [Page 19]

RFC 2156                         MIXER                      January 1998


      RFC 822 has only one (see IP Message Identification

   Non-delivery Notification
      Not supported in all cases.  Supported where the recipient system
      supports NOTARY DSNs.  In general all RFC 822 systems will return
      error reports by use of IP messages.  In other service elements,
      this pragmatic result can be treated as effective support of this
      service element.

   Original Encoded Information Types Indication
      Supported as a new RFC 822 header (Original-Encoded-Information-
      Types:).

   Submission Time Stamp Indication
      Supported.

   Typed Body
      Support is defined in RFC 2157.

   User Capabilities Registration
      N/A (local).

2.3.1.2.  IPM Service Optional User Facilities

   This section describes support for the optional (user selectable) IPM
   services as listed in Section 19.9 of X.400 / ISO/IEC 10021- 1,
   listed here in the order given.  Section 19.9 has cross references to
   short definitions of each service.

   Additional Physical Rendition
      N/A (PDAU).

   Alternate Recipient Allowed
      Not supported.  There is no RFC 822 service equivalent to
      prohibition of alternate recipient assignment (e.g., an RFC 822
      system may freely send an undeliverable message to a local
      postmaster).  A MIXER gateway has two conformant options.  The
      first is not to gateway a message requesting prohibition of
      alternate recipient, as this control cannot be guaranteed.  This
      option supports the service, but may cause unacceptable level of
      message rejections. The second is to gateway the message on the
      basis that there is no alternate recipient service in RFC 822. RFC
      1327 allowed only the second option.   If the first option is
      shown to be operationally effective, it may be the only option in
      future versions of MIXER.

   Authorising User's Indication
      Supported.