Mapping between X.400 and RFC-822 Message Bodies
RFC 1495
Document | Type |
RFC - Proposed Standard
(August 1993; No errata)
Obsoleted by RFC 2156
Updates RFC 1327
|
|
---|---|---|---|
Authors | Marshall Rose , Harald Alvestrand , Steve Kille , Robert Miles , Steven Thompson | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 1495 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group H. Alvestrand Request for Comments: 1495 SINTEF DELAB Updates: 1327 S. Kille ISODE Consortium R. Miles Soft*Switch, Inc. M. Rose Dover Beach Consulting, Inc. S. Thompson Soft*Switch, Inc. August 1993 Mapping between X.400 and RFC-822 Message Bodies 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. Table of Contents 1. Introduction ............................................. 1 2. Approach ................................................. 2 3. Mapping between X.400 and RFC-822 Message Bodies ......... 3 3.1 Mapping from X.400 to RFC-822 ........................... 4 3.2 Mapping from RFC-822 to X.400 ........................... 5 3.2.1 Asymmetric Mappings .................................... 6 3.2.1.1 Message/External-Body ................................ 6 3.2.1.2 Message/Partial ...................................... 6 3.2.1.3 Nested Multipart Content-types ....................... 6 3.2.2 Multipart IPMS Heading Extension ....................... 7 4. Mapping between X.400 and RFC-822 Message Headers ........ 7 5. OID Assignments .......................................... 9 6. Security Considerations .................................. 9 7. Authors' Addresses ....................................... 10 8. References ............................................... 11 1. Introduction The Internet community is a large collection of networks under autonomous administration, but sharing a core set of protocols. These are known as the Internet suite of protocols (or simply "TCP/IP"). Use of electronic-mail in the Internet is defined primarily by one Alvestrand, Kille, Miles, Rose & Thompson [Page 1] RFC 1495 MHS/RFC-822 Message Body Mapping August 1993 document, STD-11, RFC-822 [1], which defines the standard format for the exchange of messages. RFC-822 has proven immensely popular; in fact, the 822-connected Internet, is larger than the scope of the IP-connected Internet. The framework provided by RFC-822 allows for memo-based textual messages. Each message consists of two parts: the headers and the body. The headers are analogous to the structured fields found in an inter-office memo, whilst the body is free-form. Both parts are encoded using ASCII. Recently, the Internet Engineering Task Force (IETF) has developed an document called, Multipurpose Internet Mail Extensions or MIME RFC-1341. The title is actually misleading. MIME defines structure for Internet message bodies. It is not an extension to RFC-822. Independently of this, the International standards community developed a different framework in 1984 (some say that's the problem). This framework is known as the OSI Message Handling System (MHS) or sometimes X.400. Since the introduction of X.400(84), there has been work ongoing for defining mappings between MHS and RFC-822. The most recent work in this area is RFC-1327 [3], which focuses primarily on translation of envelope and headers. This document is complimentary to RFC-1327 as it focuses on translation of the message body. The mappings defined are largely symmetrical with respect to MIME and MHS structuring semantics, although the MIME semantics are somewhat richer. In order to provide for reversible transformations, MHS heading extensions are used to carry the additional MIME semantics. Please send comments to the MIME-MHS mailing list: <mime-mhs@surfnet.nl>. 2. Approach The mappings have been specifically designed to provide optimal behavior for three different scenarios: (1) Allow a MIME user and an MHS user to exchange an arbitrary binary content; (2) Allow MIME content-types to "tunnel" through an MHS relay that is, two MIME users can exchange content-types without loss Alvestrand, Kille, Miles, Rose & Thompson [Page 2] RFC 1495 MHS/RFC-822 Message Body Mapping August 1993Show full document text