rfc2156.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,822 行 · 第 1/5 页
TXT
1,822 行
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
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?