rfc1148.txt

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

Network Working Group                                           S. Kille
Request for Comments 1148                      University College London
Updates: RFCs 822, 987, 1026, 1138                            March 1990


          Mapping between X.400(1988) / ISO 10021 and RFC 822

Status of this Memo

   This RFC suggests an electronic mail protocol mapping for the
   Internet community and UK Academic Community, and requests discussion
   and suggestions for improvements.  This memo does not specify an
   Internet standard.  This edition includes material lost in editing.
   Distribution of this memo is unlimited.

   This document describes a set of mappings which will enable
   interworking between systems operating the CCITT X.400 (1988)
   Recommendations on Message Handling Systems / ISO IEC 10021 Message
   Oriented Text Interchange Systems (MOTIS) [CCITT/ISO88a], 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 document is based on RFC 987 and RFC 1026 [Kille86a, Kille87a],
   which define a similar mapping for X.400 (1984).  This document does
   not obsolete the earlier ones, as its domain of application is
   different.

Specification

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

                           Table of Contents

   1.  Overview ...............................................    2
   1.1  X.400 .................................................    2
   1.2  RFC 822 ...............................................    3
   1.3  The need for conversion ...............................    4
   1.4  General approach ......................................    4
   1.5  Gatewaying Model ......................................    5
   1.6  RFC 987 ...............................................    7
   1.7  Aspects not covered ...................................    8
   1.8  Subsetting ............................................    9



Kille                                                           [Page 1]

RFC 1148               Mapping X.400(88) and 822              March 1990


   1.9  Document Structure ....................................    9
   1.10  Acknowledgements .....................................   10
   2.  Service Elements .......................................   10
   2.1  The Notion of Service Across a Gateway ................   10
   2.2  RFC 822 ...............................................   11
   2.3  X.400 .................................................   15
   3.   Basic Mappings ........................................   24
   3.1  Notation ..............................................   24
   3.2  ASCII and IA5 .........................................   25
   3.3  Standard Types ........................................   25
   3.4  Encoding ASCII in Printable String ....................   28
   4.  Addressing .............................................   29
   4.1  A textual representation of MTS.ORAddress .............   30
   4.2  Basic Representation ..................................   30
   4.3  EBNF.822-address <-> MTS.ORAddress ....................   34
   4.4  Repeated Mappings .....................................   43
   4.5  Directory Names .......................................   45
   4.6  MTS Mappings ..........................................   45
   4.7  IPMS Mappings ....... .................................   48
   5.  Detailed Mappings ......................................   52
   5.1  RFC 822 -> X.400 ......................................   52
   5.2  Return of Contents ....................................   59
   5.3  X.400 -> RFC 822 ......................................   60
   Appendix A  Differences with RFC 987 .......................   79
   1.  Introduction ...........................................   79
   2.  Service Elements .......................................   80
   3.  Basic Mappings .........................................   80
   4.  Addressing .............................................   80
   5.  Detailed Mappings ......................................   80
   6.  Appendices .............................................   81
   Appendix B  Mappings specific to the JNT Mail ..............   81
   1.  Introduction ...........................................   81
   2.  Domain Ordering ........................................   81
   3.  Acknowledge-To: ........................................   81
   4.  Trace ..................................................   82
   5.  Timezone specification .................................   82
   6.  Lack of 822-MTS originator specification ...............   82
   Appendix C  Mappings specific to UUCP Mail .................   83
   Appendix D  Object Identifier Assignment ...................   83
   Appendix E  BNF Summary ....................................   84
   Appendix F  Format of address mapping tables ...............   91
   References .................................................   92

Chapter 1 -- Overview

1.1.  X.400

   This document relates to the CCITT 1988 X.400 Series Recommendations



Kille                                                           [Page 2]

RFC 1148               Mapping X.400(88) and 822              March 1990


    / ISO IEC 10021 on the Message Oriented Text Interchange Service
   (MOTIS).  This ISO/CCITT standard is referred to in this document as
   "X.400", which is a convenient shorthand.  Any reference to the 1984
   CCITT Recommendations will be explicit.  X.400 defines an
   Interpersonal Messaging System (IPMS), making use of a store and
   forward Message Transfer System.  This document relates to the IPMS,
   and not to wider application of X.400.  It is expected that X.400
   will be implemented very widely.

1.2.  RFC 822

   RFC 822 is the current specification of the messaging standard on the
   Internet.  This standard evolved with the evolution of the network
   from the ARPANET (created by the Defense Advanced Research Projects
   Agency) to the Internet, which now involves over 1000 networks and is
   sponsored by DARPA, NSF, DOE, NASA, and NIH.  It specifies an end to
   end message format.  It is used in conjunction with a number of
   different message transfer protocol environments.

      SMTP Networks

         On the Internet and other TCP/IP networks, RFC 822 is used in
         conjunction with two other standards: RFC 821, also known as
         Simple Mail Transfer Protocol (SMTP) [Postel82a], and RFC 1034
         which is a Specification for domains and a distributed name
         service [Mockapetris87a].

      UUCP Networks

         UUCP is the UNIX to UNIX CoPy protocol, 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 use domains which conform
         to RFC 1034, but not the corresponding domain nameservers
         [Horton86a].

      Csnet

         Some portions of Csnet follow the Internet protocols.  The
         dialup portion of Csnet uses the Phonenet protocols as a
         replacement for RFC 821.  This portion uses domains which
         conform to RFC 1034, but not the corresponding domain
         nameservers.

      Bitnet

         Some parts of Bitnet and related networks use RFC 822 related
         protocols, with EBCDIC encoding.



Kille                                                           [Page 3]

RFC 1148               Mapping X.400(88) and 822              March 1990


      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 users of the IPMS
   provided by X.400 systems.  This will also be a requirement in cases
   where communities intend to make a transition to use of an X.400
   IPMS, as conversion will be needed to ensure a smooth service
   transition.  It is expected that there will be more than one gateway,
   and this specification will enable them to behave in a consistent
   manner.  Note that the term gateway is used to describe a component
   performing the protocol mappings between RFC 822 and X.400.  This is
   standard usage amongst mail implementors, but should be noted
   carefully by transport and network service implementors.

   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.  These principles are goals, and are not achieved in
   all aspects 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



Kille                                                           [Page 4]

RFC 1148               Mapping X.400(88) and 822              March 1990


           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
           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.

      5.   The specification should be reversible.  That is, a double
           transformation should bring you back to where you started.

1.5.  Gatewaying Model

1.5.1.  X.400

   X.400 defines the IPMS Abstract Service in X.420/ISO 10021-7,
   [CCITT/ISO88b] which comprises of three basic services:

      1.   Origination

      2.   Reception

      3.   Management

   Management is a local interaction between the user and the IPMS, and
   is therefore not relevant to gatewaying.  The first two services
   consist of operations to originate and receive the following two
   objects:

      1.   IPM (Interpersonal Message).  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 heading consists of
           fields containing end to end user information, such as
           subject, primary recipients (To:), and importance.

      2.   IPN (Inter Personal Notification).  A notification  about
           receipt of a given IPM at the UA level.

   The Origination service also allows for origination of a probe, which
   is an object to test whether a given IPM could be correctly received.

   The Reception service also allows for receipt of Delivery Reports
   (DR), which indicate delivery success or failure.



Kille                                                           [Page 5]

RFC 1148               Mapping X.400(88) and 822              March 1990


   These IPMS Services utilise the Message Transfer (MT) Abstract
   Service [CCITT/ISO88c].  The MT Abstract Service provides the
   following three basic services:

      1.   Submission (used by IPMS Origination)

      2.   Delivery (used by IPMS Reception)

      3.   Administration (used by IPMS Management)

   Administration is a local issue, and so does not affect this
   standard.  Submission and delivery relate primarily to the MTS
   Message (comprising Envelope and Content), which carries an IPM or
   IPN (or other uninterpreted contents).  There is also an Envelope,
   which includes an ID, an originator, and a list of recipients.
   Submission also includes the probe service, which supports the IPMS
   Probe.  Delivery also includes Reports, which indicate whether a
   given MTS Message has been delivered or not.

   The MTS is REFINED into the MTA (Message Transfer Agent) Service,
   which define the interaction between MTAs, along with the procedures
   for distributed operation.  This service provides for transfer of MTS
   Messages, Probes, and Reports.

1.5.2.  RFC 822

   RFC 822 is based on the assumption that there is an underlying
   service, which is here called the 822-MTS service.  The 822-MTS
   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.

   It is possible to achieve 2) within the RFC 822 header.  Some 822-MTS
   protocols, in particular SMTP, can provide additional functionality,
   but as these are neither mandatory in SMTP, nor available in other
   822-MTS protocols, they are not considered here.  Details of aspects
   specific to two 822-MTS protocols are given in Appendices B and C.
   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
   heading fields, although some are analogous to MTS Service Elements
   or MTA Service Elements.





Kille                                                           [Page 6]

RFC 1148               Mapping X.400(88) and 822              March 1990


1.5.3.  The Gateway

   Given this functional description of the two services, the functional
   nature of a gateway can now be considered.  It would be elegant to
   consider the 822-MTS service mapping onto the MTS Service Elements
   and RFC 822 mapping onto an IPM, but reality just does not fit.
   Another elegant approach would be to treat this document as the
   definition of an X.400 Access Unit (AU).  Again, reality does not
   fit.  It is necessary to consider that the IPM format definition, the
   IPMS Service Elements, the MTS Service Elements, and MTA Service
   Elements on one side are mapped into RFC 822 + 822-MTS on the other
   in a slightly tangled manner.  The details of the tangle will be made
   clear in Chapter 5.  Access to the MTA Service Elements is minimised.

   The following basic mappings are thus defined.  When going from RFC
   822 to X.400, an RFC 822 message and the associated 822-MTS
   information is always mapped into an IPM (MTA, MTS, and IPMS
   Services).  Going from X.400 to RFC 822, an RFC 822 message and the
   associated 822-MTS information may be derived from:

      1.   A Report (MTA, and MTS Services)

      2.   An IPN (MTA, MTS, and IPMS Services)