rfc2156.txt

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

   2.   An IPM (MTA, MTS, and IPMS services)

   A Report (MTA, and MTS Services) is mapped onto a delivery status
   notification.

   Probes (MTA Service) shall be processed by the gateway, as discussed
   in Chapter 5.  MTS Messages containing Content Types other than those
   defined by the IPMS are not mapped by the gateway, and shall be
   rejected at the gateway if no other gatewaying procedure is defined.

   This specification is concerned with X.400 IPMS.  Future
   specifications may defined mappings for other X.400 content types.








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


1.5.4.  Repeated Mappings

   The primary goal of this specification is to support single mappings,
   so that X.400 and RFC 822 users can communicate with maximum
   functionality.

   The mappings specified here are designed to work where a message
   traverses multiple times between X.400 and RFC 822. This is often
   essential, particularly in the case of distribution lists.  However,
   in general, this will lead to a level of service which is the lowest
   common denominator (approximately the services offered by RFC 822).

   Some RFC 822 networks may wish to use X.400 as an interconnection
   mechanism (typically for policy reasons), and this is fully
   supported.

   Where an X.400 message transfers to RFC 822 and then back to X.400,
   there is no expectation of X.400 services which do not have an
   equivalent service in standard RFC 822 being preserved - although
   this may be possible in some cases.

1.6.  Support of X.400 (1984)

   The MIXER definition is based on the initial specification of RFC 987
   and in its addendum RFC 1026, which defined a mapping between
   X.400(1984) and RFC 822.  The core MIXER mapping is defined using the
   full 1988 version of X.400, and not to a 1984 compatible subset. New
   features of X.400(1988) can be used to provide a much cleaner mapping
   than that defined in RFC 987.  To interwork with 1984 systems,
   Appendix B shall be followed.

   If a message is being transferred to an X.400(1984) system by way of
   X.400(1988) MTA it will give a slightly better service to follow the
   rules of Appendix B, than to downgrade without this knowledge.
   Downgrading specifications which supplement those specified in X.400
   (X.419) are given in RFC 1328 [22] and RFC 1496 (HARPOON) [5].

1.7.  X.400 (1992)

   X.400 (1992) features are not used by the core of this mapping, and
   so there is not an equivalent downgrade problem.

1.8.  MIME

   MIME format messages are generated by this mapping.  As MIME messages
   are fully RFC 822 compliant, this will not cause problems with
   systems which are not MIME capable.




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


1.9.  Body Parts

   MIME and X.400 IPMS can both carry arbitrary body parts. MIME defines
   a mechanism for adding new body parts, and new body parts are
   registered with the IANA. X.400 defines a mechanism adding new body
   parts, usually referred to as Body Part 15.  Extensions are defined
   by Object Identifiers, so there is no requirement for a central body
   part registration authority.  The Electronic Messaging Association
   (EMA) maintains a list of some commonly used body parts.  The EMA has
   specified a mechanism to use the File Transfer Body Part (FTBP) as a
   more generic means to support message attachments.  This approach is
   gaining widespread commercial support.

   The mapping between X.400 and MIME body parts is defined in the
   companion MIXER specification, referenced here as RFC 2157 [8].  This
   document is an update of RFC 1494 [6].

   Editor's Note:
      References to 2157 will be resolved as these two
      documents are expected to progress in parallel.

   These two specifications together form the complete MIXER Mapping.

1.10.  Local and Global Scenarios

   There are two basic scenarios for X.400/MIME interworking:

   Global Scenario

      There are two global mail networks (Internet/MIME and X.400),
      interconnected by multiple gateways.   Objects may be transferred
      over multiple gateways, and so it is important that gateways
      behave in a coherent fashion.  MIXER is critical to support this
      scenario.

   Local Scenario

      A gateway is used to connect a closed community to a global mail
      network (this could be enforced by connectivity or gateway
      authorisation policy).  This is a common commercial scenario.
      MIXER is useful to support this scenario, as it allows an industry
      standard provision of service, but this could be supported by
      something which was MIXER-like.

   A solution for the global scenario will work for the local scenario.
   However, there are aspects of MIXER which have significant
   implementation or deployment effort (the global mapping is the major
   one, but there are other details too) which and are needed to support



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


   the global scenario, but are not needed in the local scenario.

   Note that the local scenario may be the driving force for most
   deployments, and support of the global scenario may be an important
   secondary goal.

   There is also a transition effect.  Gateways which are initially
   deployed in a strict local scenario situation start to find
   themselves in a global scenario.  A common case is ADMD provided
   gateways, which are targeted strictly at the local scenario.  In
   practice they soon start to operate in the global scenario, because
   of distribution lists and messages exchanged with X.400 users that
   are not customers of the ADMD.  At this point, users are hurt by the
   restrictions of a local scenario gateway.

   Note that conformance to MIXER applies to an instantiation of a
   gateway, not just an implementation (although clearly it is critical
   that the implementation is capable of being operated in a conformant
   manner).

   MIXER's conformance target is the global scenario, and the
   specification of MIXER defines operation in this way.

1.11.  Compatibility with previous versions

   The changes between this and older versions of the document are given
   in Appendices H, I and J.  These are RFCs 987, 1026, 1138, 1148 and
   1327.  This document is a revision of RFC 1327 [21].  As far as
   possible, changes have been made in a compatible fashion.

1.12.  Aspects not covered

   There have been a number of cases where previous versions of this
   document were used in a manner which was not intended.  This section
   is to make clear some limitations of scope.  In particular, this
   specification does not specify:

   -    Extensions of RFC 822 to provide access to all X.400
        services

   -    X.400 user interface definition

   These are really coupled.  To map the X.400 services, this
   specification defines a number of extensions to RFC 822.  As a side
   effect, these give the 822 user access to SOME X.400 services.
   However, the aim on the RFC 822 side is to preserve current service,
   and it is intentional that access is not given to all X.400 services.
   Thus, it will be a poor choice for X.400 implementors to use MIXER as



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


   an interface - there are too many aspects of X.400 which cannot be
   accessed through it.  If a text interface is desired, a specification
   targeted at X.400, without RFC 822 restrictions, would be more
   appropriate.  Some optional and limited extensions in this area have
   proved useful, and are defined in Appendix C.

1.13.  Subsetting

   This proposal specifies a mapping which is appropriate to preserve
   services in existing RFC 822 communities.  Implementations and
   specifications which subset this specification are non-conformant and
   strongly discouraged.

1.14.  Specification Language

   ISO and Internet standards have clear definitions as to the style of
   language used.  This specification maps between ISO/ITU-T protocol
   and Internet protocols.  This document uses ISO terminology for the
   following reasons:

   1.   This was done in previous versions.

   2.   ISO language may be mechanically converted to Internet
        language, but not vice versa.

   The key elements of the ISO rules are:

   1.   All mandatory features shall clearly be indicated by
        imperative statements or the word "shall" or "shall not".

   2.   Optional features shall be indicated by the word "may".

   3.   The word "should" and the phrase "may not" shall not be
        used.

   In some cases the specification issues guidance on use of optional
   features, by use of the the phrase word "recommended" or "not
   recommended".

   To interpet this document according to Internet rules, replace every
   occurrence of "shall" with "must".

1.15.  Related Specifications

   Mappings between Mail-11 and X.400 and Mail-11 and RFC 822 are
   described in RFC 2162, using mappings related to those defined here
   [2].




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


1.16.  Document Structure

   This document has five chapters:

   1.   Overview - this chapter.

   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 OR
        names and RFC 822 addresses, which is a fundamental gateway
        component.

   5.   Detailed Mappings - This describes the details of all other
        mappings.

   There are also ten appendices.

   WARNING:

      THE REMAINDER OF THIS SPECIFICATION IS TECHNICALLY DETAILED.  IT
      WILL NOT MAKE SENSE, EXCEPT IN THE CONTEXT OF RFC 822 AND X.400
      (1988).  DO NOT ATTEMPT TO READ THIS DOCUMENT UNLESS YOU ARE
      FAMILIAR WITH THESE SPECIFICATIONS.

1.17.  Acknowledgements

   The work in this specification was substantially based on RFC 987 and
   RFC 1148, which had input from many people, who are credited in the
   respective documents.

   A number of comments from people on RFC 1148 lead to RFC 1327.  In
   particular, there were comments and suggestions from: Maurice Abraham
   (HP); Harald Alvestrand (Sintef); Peter Cowen (X-Tel); Jim Craigie
   (JNT); Ella Gardner (MITRE); Christian Huitema (Inria); Erik Huizer
   (SURFnet); Neil Jones (DEC); Ignacio Martinez (IRIS); Julian Onions
   (X-Tel); Simon Poole (SWITCH); Clive Roberts (Data General); Pete
   Vanderbilt (SUN); Alan Young (Concurrent).

   RFC 1327 has been widely adopted, and a review team was formed.  This
   comprised of: Urs Eppenberger (SWITCH)(Chair); Claudio Allocchio
   (INFN); Harald Alvestrand (UNINETT); Dave Crocker (Brandenburg); Ned
   Freed (Innosoft); Erik Huizer (SURFnet); Steve Kille (Isode); Peter
   Sylvester (GC Tech).



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


   Harald Alvestrand also supplied the tables mapping DSN status codes
   with X.400 codes.  Ned Freed defined parts of the File Transfer Body
   Part mapping.

   Comment and input has also been received from: Bengt Ackzell (Generic
   Systems); Samir Albadine (Transpac); Mark Boyes (DEC); Larry Campbell
   (Boston Software Works); Jacqui Caren (Cray); Allan Cargille (MCI);
   Kevin Carrosso (Innosoft); Charlie Combs (OIW); Jim Craigie (Net-
   Tel); Eamon Doyle (Isocor); Efifion Edem (SITA); Jyrki Heikkinen
   (ICL); Edward Hibbert (DCL); Jeroun Houttin (Terena); Kevin Jordan
   (CDS); Paul Kingsnorth (DEC); Carl-Uno Manros (Manros Consulting);
   Suzan Mendes (Telis); Robert Miles (Softswitch); Roger Mizumorri
   (Enterprise Solutions Ltd); Keith Moore (University of Tennessee);
   Ruth Moulton (Net-Tel) Michel Musy (Bull); Kenji Nonaka (NTT): The
   OIW MHSIG; Tom Oliphant (SWITCH); Julian Onions (NEXOR); Jacob Palme
   (KTH); Olivier Paridaens (ULB); Mary la Roche (Citicorp); John
   Setsaas (Maxware); Russell Sharpe (DCL); Patrick Soulier (CCETT);
   Eftimios Tsigros (Universite Libre de Bruxelles); Sean Turner (IECA);
   Mark Wahl (Isode); David Wilson (Isode); Bill Wohler (Worldtalk);
   Alan Young (Isode); Alain Zahm (Telis).

Chapter 2 - Service Elements

   This chapter considers the services offered across a gateway built
   according to this specification.  It gives a view of the
   functionality provided by such a gateway for communication with users
   in the opposite domain.  This chapter considers service mappings in
   the context of SINGLE transfers only, and not repeated mappings
   through multiple gateways.

2.1.  The Notion of Service Across a Gateway

   RFC 822 and X.400 provide a number of services to the end user.  This
   chapter 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.

2.1.1.  Origination of Messages

   When a user originates a message, a number of services are available.
   Some of these imply actions (e.g., delivery to a recipient), and some
   are insertion of known data (e.g., specification of a subject field).
   This chapter describes, for each offered service, to what extent it
   is supported for a recipient accessed through a gateway.  There are
   three levels of support:





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


   Supported
      The corresponding protocol elements map well, and so the service
      can be fully provided.

   Not Supported
      The service cannot be provided, as there is a complete mismatch.

   Partial Support
      The service can be partially fulfilled.

   In the first two cases, the service is simply marked as "Supported"
   or "Not Supported".  Some explanation may be given if there are