rfc1327.txt

RFC 的详细文档！

Network Working Group                                S. Hardcastle-Kille
Request for Comments: 1327                     University College London
Obsoletes: RFCs 987, 1026, 1138, 1148                           May 1992
Updates: RFC 822


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

Status of this Memo

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Abstract

   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 a revision based on RFCs 987, 1026, 1138, and 1148
   [Kille86a,Kille87a] which it obsoletes.

   This document specifies a mapping between two protocols.  This
   specification should be used when this mapping is performed on the
   DARPA 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 ......................................    3
   1.1        - X.400 .........................................    3
   1.2        - RFC 822 .......................................    3
   1.3        - The need for conversion .......................    4
   1.4        - General approach ..............................    4
   1.5        - Gatewaying Model ..............................    5
   1.6        - X.400 (1984) ..................................    8
   1.7        - Compatibility with previous versions ..........    8
   1.8        - Aspects not covered ...........................    8
   1.9        - Subsetting ....................................    9
   1.10       - Document Structure ............................    9



Hardcastle-Kille                                                [Page 1]

RFC 1327        Mapping between X.400(1988) and RFC 822         May 1992


   1.11       - Acknowledgements ..............................    9
   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 .................................   26
   3.3        - Standard Types ................................   26
   3.4        - Encoding ASCII in Printable String ............   28
   4          - Addressing ....................................   30
   4.1        - A textual representation of MTS.ORAddress .....   30
   4.2        - Basic Representation ..........................   31
   4.3        - EBNF.822-address <-> MTS.ORAddress ............   36
   4.4        - Repeated Mappings .............................   48
   4.5        - Directory Names ...............................   50
   4.6        - MTS Mappings ..................................   50
   4.7        - IPMS Mappings .................................   55
   5          - Detailed Mappings .............................   59
   5.1        - RFC 822 -> X.400 ..............................   59
   5.2        - Return of Contents ............................   67
   5.3        - X.400 -> RFC 822 ..............................   67
   Appendix A - Mappings Specific to SMTP .....................   91
   Appendix B - Mappings specific to the JNT Mail .............   91
   1          - Introduction ..................................   91
   2          - Domain Ordering ...............................   91
   3          - Addressing ....................................   91
   4          - Acknowledge-To:  ..............................   91
   5          - Trace .........................................   92
   6          - Timezone specification ........................   92
   7          - Lack of 822-MTS originator specification ......   92
   Appendix C - Mappings specific to UUCP Mail ................   93
   Appendix D - Object Identifier Assignment ..................   94
   Appendix E - BNF Summary ...................................   94
   Appendix F - Format of address mapping tables ..............  101
   1          - Global Mapping Information ....................  101
   2          - Syntax Definitions ............................  102
   3          - Table Lookups .................................  103
   4          - Domain -> O/R Address format ..................  104
   5          - O/R Address -> Domain format ..................  104
   6          - Domain -> O/R Address of Gateway table ........  104
   Appendix G - Mapping with X.400(1984) ......................  105
   Appendix H - RFC 822 Extensions for X.400 access ...........  106
   Appendix I - Conformance ...................................  106
   Appendix J - Change History: RFC 987, 1026, 1138, 1148 .....  107
   1          - Introduction ..................................  108
   2          - Service Elements ..............................  108
   3          - Basic Mappings ................................  108



Hardcastle-Kille                                                [Page 2]

RFC 1327        Mapping between X.400(1988) and RFC 822         May 1992


   4          - Addressing ....................................  108
   5          - Detailed Mappings .............................  109
   6          - Appendices ....................................  109
   Appendix K - Change History: RFC 1148 to this Document .....  109
   1          - General .......................................  109
   2          - Basic Mappings ................................  110
   3          - Addressing ....................................  110
   4          - Detailed Mappings .............................  110
   5          - Appendices ....................................  110
   References .................................................  111
   Security Considerations ....................................  113
   Author's Address ...........................................  113

Chapter 1 -- Overview

1.1.  X.400

   This document relates to the CCITT 1988 X.400 Series Recommendations
   / 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 evolved as a messaging standard on the DARPA (the US Defense
   Advanced Research Projects Agency) Internet.  It specifies and end to
   end message format.  It is used in conjunction with a number of
   different message transfer protocol environments.

   SMTP Networks
       On the DARPA 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 920 which is a Specification for domains and a
       distributed name service [Postel84a].

   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 920, but not the corresponding domain
       nameservers [Horton86a].



Hardcastle-Kille                                                [Page 3]

RFC 1327        Mapping between X.400(1988) and RFC 822         May 1992


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

   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.



Hardcastle-Kille                                                [Page 4]

RFC 1327        Mapping between X.400(1988) and RFC 822         May 1992


   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
        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.   Subject to 1), 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.



Hardcastle-Kille                                                [Page 5]

RFC 1327        Mapping between X.400(1988) and RFC 822         May 1992


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

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



Hardcastle-Kille                                                [Page 6]

RFC 1327        Mapping between X.400(1988) and RFC 822         May 1992


   or MTA Service Elements.

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