rfc987.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,941 行 · 第 1/5 页

UCL Technical Report 120
Mailgroup Note 19

Network Working Group                                         S.E. Kille
Request for Comments: 987                      University College London
                                                               June 1986

                   Mapping between X.400 and RFC 822


Status of This Memo

   This RFC suggests a proposed protocol for the ARPA-Internet
   community, and requests discussion and suggestions for improvements.
   Distribution of this memo is unlimited.

   This document describes a set of mappings which will enable
   interworking between systems operating the CCITT X.400 (1984) series
   of protocols [CCITT84a], and systems using the RFC 822 mail protocol
   [Crocker82a], or protocols derived from RFC 822.  The approach aims
   to maximise the services offered across the boundary, whilst not
   requiring unduly complex mappings.  The mappings should not require
   any changes to end systems.

   This specification should be used when this mapping is performed on
   the ARPA-Internet or in the UK Academic Community.  This
   specification may be modified in the light of implementation
   experience, but no substantial changes are expected.

























Kille                                                           [Page 1]



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


Chapter 1 -- Overview

   1.1.  X.400

      The X.400 series protocols have been defined by CCITT to provide
      an Interpersonal Messaging Service (IPMS), making use of a store
      and forward Message Transfer Service.  It is expected that this
      standard will be implemented very widely.  As well as the base
      standard (X.400), work is underway on various functional standards
      of profiles which specify how X.400 will be used in various
      communities.  Many of the major functional standards (e.g. from
      CEPT, CEN/CENELEC, and NBS) are likely to be similar.  Some of the
      decisions in this document are in the light of this work.  No
      reference is given, as these documents are not currently stable.

   1.2.  RFC 822

      RFC 822 evolved as a messaging standard on the DARPA (the US
      Defense Advanced Research Projects Agency) Internet.  It is
      currently used on the ARPA-Internet in conjunction with two other
      standards: RFC 821, also known as Simple Mail Transfer Protocol
      (SMTP) [Postel82a], and RFC 920 which is a specification for a
      domain name system and a distributed name service [Postel84a].
      RFC 822, or protocols derived from RFC 822 are used in a number of
      other networks.  In particular:

         UUCP Networks

            UUCP is the UNIX to UNIX CoPy protocol <0>, which is usually
            used over dialup telephone networks to provide a simple
            message transfer mechanism.  There are some extensions to
            RFC 822, particularly in the addressing.  They are likely to
            use domains which conform to RFC 920, but not the
            corresponding domain nameservers [Horton86a].

         CSNET

            Some portions of CSNET will follow the ARPA-Internet
            protocols. The dialup portion of CSNET uses the Phonenet
            protocols as a replacement for RFC 821.  This portion is
            likely to use domains which conform to RFC 920, but not the
            corresponding domain nameservers.

         BITNET

            Some parts of BITNET use RFC 822 related protocols, with
            EBCDIC encoding.


Kille                                                           [Page 2]



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


         JNT Mail Networks

            A number of X.25 networks, particularly those associated
            with the UK Academic Community, use the JNT (Joint Network
            Team) Mail Protocol, also known as Greybook [Kille84a].
            This is used with domains and name service specified by the
            JNT NRS (Name Registration Scheme) [Larmouth83a].

      The mappings specified here are appropriate for all of these
      networks.

   1.3.  The Need for Conversion

      There is a large community using RFC 822 based protocols for mail
      services, who will wish to communicate with X.400 systems.  This
      will be a requirement, even in cases where communities intend to
      make a transition to use of X.400, where conversion will be needed
      to ensure a smooth service transition.  It is expected that there
      will be more than one gateway <1>, and this specification will
      enable them to behave in a consistent manner.  These gateways are
      sometimes called mail relays.  Consistency between gateways is
      desirable to provide:

         1.   Consistent service to users.

         2.   The best service in cases where a message passes through
              multiple gateways.

   1.4.  General Approach

      There are a number of basic principles underlying the details of
      the specification.

         1.   The specification should be pragmatic.  There should not
              be a requirement for complex mappings for 'Academic'
              reasons.  Complex mappings should not be required to
              support trivial additional functionality.

         2.   Subject to 1), functionality across a gateway should be as
              high as possible.

         3.   It is always a bad idea to lose information as a result of
              any transformation.  Hence, it is a bad idea for a gateway
              to discard information in the objects it processes.  This
              includes requested services which cannot be fully mapped.

         4.   All mail gateways actually operate at exactly one level


Kille                                                           [Page 3]



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


              above the layer on which they conceptually operate.  This
              implies that the gateway must not only be cognisant of the
              semantics of objects at the gateway level, but also be
              cognisant of higher level semantics.  If meaningful
              transformation of the objects that the gateway operates on
              is to occur, then the gateway needs to understand more
              than the objects themselves.

   1.5.  Gatewaying Model

      1.5.1.  X.400

         The CCITT X.400 series recommendations specify a number of
         services and protocols.  The services are specified in X.400.
         Two of these services are fundamental to this document:

            1.   The Message Transfer Service, which can be provided by
                 either the P1 or P3 protocols, which are  specified in
                 X.411 [CCITT84b]. This document talks in terms of P1,
                 but the mappings are equally applicable to P3.

            2.   The Interpersonal Messaging Service (IPMS), which is
                 provided by the P2 protocol specified in X.420
                 [CCITT84c].

         This document considers only IPMS, and not of any other usage
         of the Message Transfer Service.  This is reasonable, as
         RFC 822, broadly speaking, provides a service corresponding to
         IPMS, and no services other than IPMS have been defined over
         the Message Transfer Service. As none of the RTS (Reliable
         Transfer Service) service elements is available to the IPMS
         user, this level and lower levels are of no concern in this
         gatewaying specification.  Note that in this memo "IP" means
         "InterPersonal" (not Internet Protocol).

         The Message Transfer Service defines an end-to-end service over
         a series of Message Transfer Agents (MTA).  It also defines a
         protocol, P1, which is used between a pair of MTAs.  This
         protocol is simply a file format (Message Protocol Data Unit,
         or MPDU), transferred between two MTAs using the RTS.  There
         are three types of MPDU:

            User MPDU

               This contains envelope information, and uninterpreted
               contents. The envelope includes an ID, an originator, a



Kille                                                           [Page 4]



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


               list of recipients, and trace information.  It is used to
               carry data for higher level services.

            Probe

               This contains only envelope information.  It is used to
               determine whether a User UMPDU could be delivered to a
               given O/R (originator/recipient) name.

            Delivery Report

               This contains envelope information, and specified
               contents.  It is used to indicate delivery success or
               failure of a User or Probe MPDU over the Message Transfer
               Service.

         IPMS (P2) specifies two content types for the P1 User MPDU
         (User Agent Protocol Data Units or UAPDU):

            Interpersonal Message (IM-UAPDU)

               This has two components: a heading, and a body.  The body
               is structured as a sequence of body parts, which may be
               basic components (e.g.IA5 text, or G3 fax), or IP
               Messages.  The header contains end to end user
               information, such as subject, primary recipients (To:),
               and priority.  The validity of these fields is not
               guaranteed by the Message Transfer Service.  This
               provides the basic IPMS.

            Status Report (SR-UAPDU)

               This UAPDU has defined contents.  It is used to indicate
               that a message has been received by a User Agent.  It
               does not have to be implemented.

      1.5.2.  RFC 822

         RFC 822 is based on the assumption that there is an underlying
         service, which is here called the 822-P1 service.  The 822-P1
         service provides three basic functions:

            1.   Identification of a list of recipients.

            2.   Identification of an error return address.

            3.   Transfer of an RFC 822 message.


Kille                                                           [Page 5]



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


         It is possible to achieve 2) within the RFC 822 header.  Some
         822-P1 protocols, in particular SMTP, can provide additional
         functionality, but as these are neither mandatory in SMTP, nor
         available in other 822-P1 protocols, they are not considered
         here.  Details of aspects specific to a number of 822-P1
         protocols are given in appendices B to E.  An RFC 822 message
         consists of a header, and content which is uninterpreted ASCII
         text.  The header is divided into fields, which are the
         protocol elements.  Most of these fields are analogous to P2
         header elements, although some are analogous to P1 envelope
         elements.

      1.5.3.  The Gateway

         Given this functional description of the two protocols, the
         functional nature of a gateway can now be considered.  It would
         be elegant to consider the 822-P1 service mapping onto P1 and
         RFC 822 mapping onto P2, but reality just does not fit.
         Therefore one must consider that P1 or P1 + P2 on one side are
         mapped into RFC 822 + 822-P1 on the other in a slightly tangled
         manner.  The details of the tangle will be made clear in
         chapter 5.  The following basic mappings are thus proposed.
         When going from RFC 822 to X.400, an RFC 822 message and the
         associated 822-P1 information is always mapped into an IM-UAPDU
         and the associated P1 envelope.  Going from X.400 to RFC 822,
         an RFC 822 message and the associated 822-P1 information may be
         derived from:

            1.   A Delivery Report MPDU

            2.   An SR-UAPDU and the associated P1 envelope.

            3.   An IM-UAPDU and the associated P1 envelope.

         Probe MPDUs must be processed by the gateway - this is
         discussed in chapter 5.  Any other User MPDUs are not mapped by
         the gateway, and should be rejected at the gateway.












Kille                                                           [Page 6]



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


   1.6.  Document Structure

      This document has five chapters:

         1.   Overview - this document.

         2.   Service Elements - This describes the (end user) services
              mapped by a gateway.

         3.   Basic mappings - This describes some basic notation used
              in chapters 3-5, the mappings between character sets, and
              some fundamental protocol elements.

         4.   Addressing - This considers the mapping between X.400 O/R
              names and RFC 822 addresses, which is a fundamental
              gateway component.

         5.   Protocol Elements - This describes the details of all
              other mappings.

      There are also six appendices:

         A.   Quoted String Encodings.

         B.   Mappings Specific to JNT Mail.

         C.   Mappings Specific to Internet Mail.

         D.   Mappings Specific to Phonenet Mail.

         E.   Mappings Specific to UUCP Mail.

         F.   Format of Address Tables.

   1.7.  Acknowledgements

      This document is eclectic, and credit should be given:

         -    Study of the EAN X.400 system code which performs this
              function [Neufeld85a].  Some detailed clarification was
              made by the DFN report on EAN [Bonacker85a].