rfc2156.txt

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

Network Working Group                                         S. Kille
Request for Comments: 2156                                  Isode Ltd.
Obsoletes: 987, 1026, 1138, 1148, 1327, 1495              January 1998
Updates: 822
Category: Standards Track


              MIXER (Mime Internet X.400 Enhanced Relay):
                 Mapping between X.400 and RFC 822/MIME

Status of this Memo

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

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Table of Contents

   1          - Overview ......................................    3
   1.1        - X.400 .........................................    3
   1.2        - RFC 822 and MIME ..............................    3
   1.3        - The need for conversion .......................    4
   1.4        - General approach ..............................    4
   1.5        - Gatewaying Model ..............................    5
   1.6        - Support of X.400 (1984) .......................    8
   1.7        - X.400 (1992) ..................................    8
   1.8        - MIME ..........................................    8
   1.9        - Body Parts ....................................    8
   1.10       - Local and Global Scenarios ....................    9
   1.11       - Compatibility with previous versions ..........   10
   1.12       - Aspects not covered ...........................   10
   1.13       - Subsetting ....................................   11
   1.14       - Specification Language ........................   11
   1.15       - Related Specifications ........................   11
   1.16       - Document Structure ............................   12
   1.17       - Acknowledgements ..............................   12
   2          - Service Elements ..............................   13
   2.1        - The Notion of Service Across a Gateway ........   13
   2.2        - RFC 822 .......................................   15
   2.3        - X.400 .........................................   18
   3          - Basic Mappings ................................   27
   3.1        - Notation ......................................   27



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


   3.2        - ASCII and IA5 .................................   29
   3.3        - Standard Types ................................   29
   3.4        - Encoding ASCII in Printable String ............   33
   3.5        - RFC 1522 ......................................   34
   4          - Addressing and Message IDs ....................   35
   4.1        - A textual representation of MTS.ORAddress .....   36
   4.2        - Global Address Mapping ........................   43
   4.3        - EBNF.822-address <-> MTS.ORAddress ............   46
   4.4        - Repeated Mappings .............................   59
   4.5        - Directory Names ...............................   62
   4.6        - MTS Mappings ..................................   62
   4.7        - IPMS Mappings .................................   67
   5          - Detailed Mappings .............................   71
   5.1        - RFC 822 -> X.400: Detailed Mappings ...........   71
   5.2        - Return of Contents ............................   86
   5.3        - X.400 -> RFC 822: Detailed Mappings ...........   86
   Appendix A - Mappings Specific to SMTP .....................  114
   1          - Probes ........................................  114
   2          - Long Lines ....................................  114
   3          - SMTP Extensions ...............................  114
   3.1        - SMTP Extension mapping to X.400 ...............  114
   3.2        - X.400 Mapping to SMTP Extensions ..............  115
   Appendix B - Mapping with X.400(1984) ......................  116
   Appendix C - RFC 822 Extensions for X.400 access ...........  118
   Appendix D - Object Identifier Assignment ..................  119
   Appendix E - BNF Summary ...................................  120
   Appendix F - Text format for MCGAM distribution ............  127
   1          - Text Formats ..................................  127
   2          - Mechanisms to register and to distribute
                MCGAMs ........................................  127
   3          - Syntax Definitions ............................  128
   4          - Table Lookups .................................  129
   5          - Domain -> OR Address MCGAM format .............  129
   6          - OR Address -> Domain MCGAM format .............  129
   7          - Domain -> OR Address of Preferred Gateway
                table .........................................  130
   8          - OR Addresss -> domain of Preferred Gateway
                table .........................................  130
   Appendix G - Conformance ...................................  131
   Appendix H - Change History: RFC 987, 1026, 1138, 1148
                ...............................................  133
   1          - Introduction ..................................  133
   2          - Service Elements ..............................  133
   3          - Basic Mappings ................................  133
   4          - Addressing ....................................  134
   5          - Detailed Mappings .............................  134
   6          - Appendices ....................................  134
   Appendix I - Change History: RFC 1148 to RFC 1327 ..........  135



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


   1          - General .......................................  135
   2          - Basic Mappings ................................  135
   3          - Addressing ....................................  135
   4          - Detailed Mappings .............................  135
   5          - Appendices ....................................  136
   Appendix J - Change History: RFC 1327 to this Document
                ...............................................  137
   1          - General .......................................  137
   2          - Service Elements ..............................  137
   3          - Basic Mappings ................................  137
   4          - Addressing ....................................  137
   5          - Detailed Mappings .............................  138
   6          - Appendices ....................................  138
   Appendix L - ASN.1 Summary .................................  139
   Security Considerations ....................................  141
   Author's Address ...........................................  141
   References .................................................  141
   Full Copyright Statement ...................................  144

Chapter 1 -- Overview

1.1.  X.400

   This document relates primarily to the ITU-T 1988 and 1992 X.400
   Series Recommendations / ISO IEC 10021 International Standard.  This
   ISO/ITU-T standard is referred to in this document as "X.400", which
   is a convenient shorthand.  Any reference to the 1984 Recommendations
   will be explicit.  Any mappings relating to elements which are in the
   1992 version and not in the 1988 version will be noted explicitly.
   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, such as EDI as
   defined in X.435.

1.2.  RFC 822 and MIME

   RFC 822 evolved as a messaging standard on the DARPA (the US Defense
   Advanced Research Projects Agency) Internet.  RFC 822 specifies an
   end to end message format, consisting of a header and an unstructured
   text body.  MIME (Multipurpose Internet Mail Extensions) specifies a
   structured message body format for use with RFC 822.  The term "RFC
   822" is used in this document to refer to the combination of MIME and
   RFC 822. RFC 822 and MIME are used in conjunction with a number of
   different message transfer protocol environments.  The core of the
   MIXER specification is designed to work with any supporting message
   transfer protocol.





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


   One transfer protocol, SMTP, is of particular importance and is
   covered in MIXER.  On the Internet and other TCP/IP networks, RFC 822
   is used in conjunction with RFC 821, also known as Simple Mail

   Transfer Protocol (SMTP) [30], in a manner conformant with the host
   requirements specification [10].  Use of MIXER with SMTP is defined
   in Appendix A.

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 between the different
   technologies, 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 mapping between RFC 822 and X.400.  This is standard
   usage amongst mail implementors, but differs from that used 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
        to discard information in the objects it processes.  This
        includes requested services which cannot be fully mapped.




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


   4.   Mail gateways  operate at a level above the layer on which
        they perform mappings.  This implies that the gateway shall
        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 mapping 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 , [11] 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 forwarded Interpersonal 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                       Standards Track                     [Page 5]

RFC 2156                         MIXER                      January 1998


   These IPMS Services utilise the Message Transfer System (MTS)
   Abstract Service [12].  The MTS 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).  The Envelope includes a
   message identifier, an originator, and a list of recipients.
   Submission also includes the probe service, which supports the MTS
   Probe. Delivery also includes Reports, which indicate whether a given
   MTS Message has been delivered or not (or for a probe if delivery
   would have happened).

   The MTS is provided by MTAs which interact using 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.

   This specification will be used most commonly with SMTP as the 822-
   MTS service.  The core MIXER specification is written so that it does
   not rely on non-basic 822-MTS services.  Use of non-basic SMTP
   services is described in Appendix A.  The core of this document is
   written using SMTP terminology for 822-MTS services.

   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 IPM



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


   heading fields, although some are analogous to MTS Service Elements
   or MTA Service Elements.

   RFC 822 supports delivery status notifications by use of the NOTARY
   mechanisms [28].

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 SMTP (822-MTS) service mapping onto the MTS Service
   Elements and RFC 822 mapping onto an IPM, but there is a not a clear
   match between these services.  Another elegant approach would be to
   treat this document as the definition of an X.400 Access Unit (AU).
   In this case, the abstraction level is too high, and some necessary
   mapping function is lost.  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 + SMTP 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 SMTP information
   is always mapped into an IPM (MTA, MTS, and IPMS Services) and a
   Delivery Status Notification is mapped onto a Report.  Going from
   X.400 to RFC 822, an RFC 822 message and the associated SMTP
   information may be derived from:

   1.   An IPN (MTA, MTS, and IPMS services)