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