rfc987.txt

RFC 相关的技术文档

RFC 987                                                        June 1986
Mapping between X.400 and RFC 822


         -    A document by Mark Horton [Horton85a].  The string
              encodings of chapter 3 were derived directly from this
              work, as is much of chapter 4.

         -    Discussion on a number of electronic mailing lists.

         -    Meetings in the UK and the US.










































Kille                                                           [Page 8]



RFC 987                                                        June 1986
Mapping between X.400 and RFC 822


Chapter 2 -- Service Elements

   RFC 822 and X.400 provide a number of services to the end user.  This
   document describes the extent to which each service can be supported
   across an X.400 <-> RFC 822 gateway.  The cases considered are single
   transfers across such a gateway, although the problems of multiple
   crossings are noted where appropriate.

   When a service element is described as supported, this means that
   when this service element is specified by a message originator for a
   recipient behind a gateway, that it is mapped by the gateway to
   provide the service implied by the element.  For example, 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.
   Support implies:

      -    Semantic correspondence.

      -    No loss of information.

      -    Any actions required by the service element.

   For some services, the corresponding protocol elements map well, and
   so the service can be fully provided.  In other cases, the service
   cannot be provided, as there is a complete mismatch.  In the
   remaining cases, the service can be partially fulfilled.  The level
   of partial support is summarised.

      NOTE:  It should be clear that support of service elements on
      reception is not a gatewaying issue.  It is assumed that all
      outbound messages are fully conforming to the appropriate
      standards.

   2.1.  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.  A mechanism
      of mapping used in several cases, is to place the text of the
      header into the body of the IP Message.  This can usually be
      regarded as partial support, as it allows the information to be
      conveyed to the end user even though there is no corresponding
      X.400 protocol element.  Support for the various service elements
      (headers) is now listed.




Kille                                                           [Page 9]



RFC 987                                                        June 1986
Mapping between X.400 and RFC 822


         Date:

            Supported.

         From:

            Supported.  For messages where there is also a sender field,
            the mapping is to "Authorising Addresses", 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 in msg-id form.  Other
            cases are passed in the message text.

         References:

            Supported.

         Keywords:

            Passed in the message text.



Kille                                                          [Page 10]



RFC 987                                                        June 1986
Mapping between X.400 and RFC 822


         Subject:

            Supported.

         Comments:

            Passed in the message text.

         Encrypted:

            Passed in the message text.  This may not be very useful.

         Resent-*

            Passed in the message text.  In principle, these could be
            supported in a fuller manner, but this is not suggested.

         Other Fields

            In particular X-* fields, and "illegal" fields in common
            usage (e.g. "Fruit-of-the-day:") are passed in the message
            text.

   2.2.  X.400

      When mapping from X.400 to RFC 822, it is not proposed to map any
      elements into the body of an RFC 822 message.  Rather, new RFC 822
      headers are defined.  It is intended that these fields will be
      registered, and that co-operating RFC 822 systems may use them.
      Where these new fields are used, and no system action is implied,
      the service can be regarded as being almost supported.  Chapter 5
      describes how to map these new headers in both directions.  Other
      elements are provided, in part, by the gateway as they cannot be
      provided by RFC 822.  Some service elements are are marked N/A
      (not applicable).  These elements are only applicable to User
      Agent / Message Transfer Agent interaction and have no end-to-end
      implication. These elements do not need to be mapped by the
      gateway.

      2.2.1.  Message Transfer Service Elements

         Access Management

            N/A.





Kille                                                          [Page 11]



RFC 987                                                        June 1986
Mapping between X.400 and RFC 822


         Content Type Indication

            Not mapped.  As it can only have one value (P2), there is
            little use in creating a new RFC 822 header field, unless it
            was to distinguish delivery reports.

         Converted Indication

            Supported by a new RFC 822 header.

         Delivery Time Stamp Indication

            N/A.

         Message Identification

            Supported, by use of a new RFC 822 header.  This new header
            is required, as X.400 has two message-ids whereas RFC 822
            has only one.

         Non-delivery Notification

            Not supported, although in general an RFC 822 system will
            return errors as IP messages.  In other elements, this
            pragmatic result is treated as effective support of this
            service element.

         Original Encoded Information Types Indication

            Supported as a new RFC 822 header.

         Registered Encoded Information Types

            N/A.

         Submission Time Stamp Indication

            Supported.

         Alternate Recipient Allowed

            Not supported.  Any value is ignored by the gateway.

         Deferred Delivery

            Support is optional.  The framework is provided so that
            messages may be held at the gateway.  However, a gateway


Kille                                                          [Page 12]



RFC 987                                                        June 1986
Mapping between X.400 and RFC 822


            following this specification does not have to do this.  This
            is in line with the emerging functional standards.

         Deferred Delivery Cancellation

            Supported.

         Delivery Notification

            Supported at gateway.  Thus, a notification is sent by the
            gateway to the originator  <2>.

         Disclosure of Other Recipients

            Supported by use of a new RFC 822 header.

         Grade of Delivery Selection

            Supported as a new RFC 822 header.  In general, this will
            only be for user information in the RFC 822 world.

         Multi-Destination Delivery

            Supported.

         Prevention of Non-delivery Notification

            Not Supported, as there is no control in the RFC 822 world
            (but see Non-delivery Notification).

         Return of Contents

            This is normally the case, although the user has no control
            (but see Non-delivery Notification).

         Conversion Prohibition

            Supported.  Note that in practice this support is restricted
            by the nature of the gateway.

         Explicit Conversion

            Supported, for appropriate values (See the IPMS Typed Body
            service element).





Kille                                                          [Page 13]



RFC 987                                                        June 1986
Mapping between X.400 and RFC 822


         Implicit Conversion

            Supported, in the sense that there will be implicit
            conversion to IA5 in cases where this is practical.

         Probe

            Supported at the gateway (i.e. the gateway services the
            probe).

         Alternate Recipient Assignment

            N/A.

         Hold for Delivery

            N/A.

      2.2.2.  Interpersonal Message Service Elements

         IP-message Identification

            Supported.

         Typed Body

            Supported.  IA5 is fully supported.  ForwardedIPMessage is
            supported, with some loss of information.  A subset of TTX
            is supported (see section 5 for the specification of this
            subset), with some loss of information.  SFD may be
            supported, with some loss of information.  TTX and SFD are
            only supported when conversion is allowed.  Other types are
            not supported.

         Blind Copy Recipient Indication

            Supported.

         Non-receipt Notification

            Not supported.

         Receipt Notification

            Not supported.




Kille                                                          [Page 14]



RFC 987                                                        June 1986
Mapping between X.400 and RFC 822