summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1495.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1495.txt')
-rw-r--r--doc/rfc/rfc1495.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc1495.txt b/doc/rfc/rfc1495.txt
new file mode 100644
index 0000000..fd1faf9
--- /dev/null
+++ b/doc/rfc/rfc1495.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+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 1993
+
+
+ through an MHS relay); and,
+
+ (3) Allow MHS body parts to "tunnel" through a MIME relay that is,
+ two MHS users can exchange body parts without loss through a MIME
+ relay).
+
+ Other, related, scenarios can also be easily accommodated.
+
+ To facilitate the mapping process, the Internet Assigned Numbers
+ Authority (IANA) maintains a table termed the "IANA MHS/MIME
+ Equivalence Table". Once an enterprise has registered an OID to
+ describe an MHS body part, it should complete a corresponding
+ registry with the IANA for a MIME content-type/subtype. In practice,
+ the corresponding content-type will be "application", with an
+ appropriate choice of sub-type and possible parameters. If a new
+ MIME content-type/subtype is registered with the IANA without a
+ corresponding entry in the Equivalence Table, the IANA will assign it
+ an OID, from the arc defined in this memo. See [4], section 5 for
+ details.
+
+ The companion document, "Equivalences between 1988 X.400 and RFC-822
+ Message Bodies"[4], defines the initial configuration of this table.
+ The mappings described in both this document and the companion
+ document use the notational conventions of RFC-1327.
+
+3. Mapping between X.400 and RFC-822 Message Bodies
+
+ MHS messages are comprised of an IPMS.heading and an IPMS.body. The
+ IPMS.Body is a sequence of IPMS.BodyParts. An IPMS.BodyPart may be a
+ nested message (IPMS.MessageBodyPart).
+
+ A MIME message consists of headers and a content. For the purpose of
+ discussion, the content may be structured (multipart or message), or
+ atomic (otherwise). An element of a structured content may be a
+ message or a content. Both message and structured content have
+ subtypes which do not have direct analogies in MHS.
+
+ The mapping between X.400 and RFC-822 message bodies which this
+ document defines is symmetrical for the following cases:
+
+ (1) any atomic body part
+
+ (2) multipart: digest and mixed subtypes
+
+ (3) message/rfc822
+
+ RFC-1327 specifies the mappings for headers. Section 4 describes how
+ those mappings are modified by this document. When mapping between
+
+
+
+Alvestrand, Kille, Miles, Rose & Thompson [Page 3]
+
+RFC 1495 MHS/RFC-822 Message Body Mapping August 1993
+
+
+ an MHS body and a MIME content, the following algorithm is used:
+
+3.1. Mapping from X.400 to RFC-822
+
+ This section replaces the text in RFC-1327 starting at the bottom of
+ page 84,
+
+ The IPMS.Body is mapped into the RFC-822 message body. Each
+ IPMS.BodyPart is converted to ASCII as follows:
+
+ and continuing up to and including page 86 of Section 5.3.4 of RFC-
+ 1327.
+
+ If the IPMS.Body
+
+ Body ::=
+ SEQUENCE OF
+ BodyPart
+
+ consists of a single body part, then the RFC-822 message body is
+ constructed as the MIME content corresponding to that body part.
+
+ If the body part is an IPMS.MessageBodyPart (forwarded IPM), the
+ mapping is applied recursively. Otherwise, to map a specific MHS
+ body part to a MIME content-type, the IANA MHS/MIME Equivalence table
+ is consulted. If the MHS body part is not identified in this table,
+ then the body-part is mapped onto an "application/x400-bp" content,
+ as specified in [4].
+
+ If the IPMS.Body consists of more than one body part, then the RFC-
+ 822 message body is constructed as a
+
+ multipart/mixed
+
+ content-type, unless all of the body parts are messages, in which
+ case it is mapped to a
+
+ multipart/digest
+
+ content-type. Each component of the multipart content-type
+ corresponds to a IPMS.BodyPart, preserving the ordering of the body
+ parts in the IPMS.Body.
+
+ There is one case which gets special treatement. If the IPMS.Body
+ consists solely of a single IA5Text body part, then the RFC822
+ message body is NOT marked as a MIME content. This prevents RFC822
+ mailers from invoking MIME function unnecessarily.
+
+
+
+
+Alvestrand, Kille, Miles, Rose & Thompson [Page 4]
+
+RFC 1495 MHS/RFC-822 Message Body Mapping August 1993
+
+
+3.2. Mapping from RFC-822 to X.400
+
+ First, replace the first paragraph of Section 5.1.3 on page 72 of
+ RFC-1327 to read as:
+
+ The IPM (IPMS Service Request) is generated according to the
+ rules of this section. The IPMS.body usually consists of one
+ IPMS.BodyPart of type
+
+ IPMS.IA5TextBodyPart
+
+ with
+ IPMS.IA5TextBodyPart.parameters.repertoire
+
+ set to the default (ia5), which contains the body of the RFC-822
+ message. However, if the 822.MIME-Version header field is
+ present, a special algorithm is used to generate the IPMS.body.
+
+
+ Second, replace the "Comments:" paragraph on page 74 to reads as:
+
+ Comments:
+
+ If an 822.MIME-Version header field is not present,
+ generate an IPMS.Bodypart of type
+
+ IPMS.IA5TextBodyPart
+
+ with
+
+ IPMS.IA5TextBodyPart.parameters.repertoire
+
+ set to the default (ia5), containing the value of
+ the fields, preceded by the string "Comments: ".
+ This body part shall preceed the other one.
+
+ Third, add the remainder of this section to the end of Section 5.1.3
+ of RFC-1327.
+
+ If the 822.MIME-Version header field is present, the following
+ mapping rules are used to generate the IPMS.body.
+
+ If the MIME content-type is one of:
+
+ (1) any atomic body part
+
+ (2) multipart: digest and mixed subtypes
+
+
+
+
+Alvestrand, Kille, Miles, Rose & Thompson [Page 5]
+
+RFC 1495 MHS/RFC-822 Message Body Mapping August 1993
+
+
+ (3) message/rfc822
+
+ then the symmetric mapping applies as described in Section 6.1. Note
+ that the multipart content-types should be marked with the
+ IPMS.HeadingExtension described below.
+
+ Otherwise, three cases remain, which are discussed in turn.
+
+3.2.1. Asymmetric Mappings
+
+3.2.1.1. Message/External-Body
+
+ This is mapped into a mime-body-part, as specified in [4].
+
+3.2.1.2. Message/Partial
+
+ This is mapped onto a message, and the following heading extension is
+ used. The extension is derived from the message/partial parameters:
+
+ partial-message HEADING-EXTENSION
+ VALUE PartialMessage
+ ::= id-hex-partial-message
+
+ PartialMessage ::=
+ SEQUENCE {
+ number INTEGER,
+ total INTEGER,
+ id IA5String
+ }
+
+ If this heading is present when mapping from MHS to MIME, then a
+ message/partial should be generated.
+
+3.2.1.3. Nested Multipart Content-types
+
+ In MIME, a multipart content refers to a set of content-types, not a
+ message with a set of content-types. However, a nested multipart
+ content will always be mapped to an IPMS.MessageBodyPart, with an
+ IPMS.BodyPart for each contained content-type.
+
+ The only mandatory field in the heading is the IPMS.this-IPM, which
+ must always be generated (by the gateway). A IPMS.subject field
+ should also be generated where there is no "real" heading. This will
+ present useful information to the non-MIME capable X.400(88) and to
+ all X.400(84) UAs.
+
+
+
+
+
+
+Alvestrand, Kille, Miles, Rose & Thompson [Page 6]
+
+RFC 1495 MHS/RFC-822 Message Body Mapping August 1993
+
+
+ The IPM.subject fields for the various types are:
+
+ mixed: "Multipart Message"
+ alternative: "Alternate Body Parts containing the same information"
+ digest: "Message Digest"
+ parallel: "Body Parts to be interpreted in parallel"
+
+3.2.2. Multipart IPMS Heading Extension
+
+ The following IPMS.HeadingExtension should be generated for all
+ multipart content-types, with the enumerated value set according to
+ the subtype:
+
+ multipart-message HEADING-EXTENSION
+ VALUE MultipartType
+ ::= id-hex-multipart-message
+
+ MultipartType ::=
+ ENUMERATED {
+ mixed(1),
+ alternative(2),
+ digest(3),
+ parallel(4)
+ }
+
+ If this heading is present when mapping from MHS to MIME, then the
+ appropriate multipart content-type should be generated.
+
+4. Mapping between X.400 and RFC-822 Message Headers
+
+ Replace the first paragraph of Section 3.3.4 on page 26 of RFC-1327
+ to read as:
+ In cases where T.61 strings are used only for conveying human-
+ interpreted information, the aim of this mapping is to render
+ the characters appropriately in the remote character set, rather
+ than to maximize reversibility. For these cases, the following
+ steps are followed to find an appropriate encoding:
+
+ 1) If all the characters in the string are contained within the
+ ASCII repertoire, the string is simply copied.
+
+ 2) If all the characters in the string are from an IANA-
+ registered character set, then the appropriate encoded-word(s)
+ according to [5] are generated instead.
+
+ 3) If the characters in the string are from a character set
+ which is not registered with the IANA, then the mappings to IA5
+ defined in CCITT Recommendation X.408 (1988) shall be used
+
+
+
+Alvestrand, Kille, Miles, Rose & Thompson [Page 7]
+
+RFC 1495 MHS/RFC-822 Message Body Mapping August 1993
+
+
+ [CCITT/ISO88a]. These will then be encoded in ASCII.
+
+ This approach will only be used for human-readable information
+ (Subject and FreeForm Name).
+
+ When mapping from an RFC-822 header, when an encoded-word (as
+ defined in [5]) is encountered:
+
+ 1) If all the characters contained therein are mappable to T.61,
+ the string content shall be converted into T.61.
+
+ 2) Otherwise, the encoded-word shall be copied directly into the
+ T.61 string.
+
+ Modify procedure "2a" on page 56 of RFC-1327 to read as:
+ If the IPMS.ORDescriptor.free-form-name is present, convert it
+ to ASCII or T.61 (Section 3.3.4), and use this as the 822.phrase
+ component of the 822.mailbox construct.
+
+ Modify the final paragraph of procedure "2" on page 55 of RFC-1327 to
+ read as:
+ The string is then encoded into T.61 or ASCII using a human-
+ oriented mapping (as described in Section 3.3.4). If the string
+ is not null, it is assigned to IPMS.ORDescriptor.free-form.name.
+
+ Modify the second paragraph of procedure "3" on page 55 of RFC-1327
+ to read as:
+ If the 822.group construct is present, any included 822.mailbox
+ is encoded as above to generate a separate IPMS.ORDescriptor.
+ The 822.group is mapped to T.61 or ASCII (as described in
+ Section 3.3.4), and an IPMS.ORDescriptor with only an free-
+ form-name component is built from it.
+
+ Modify procedure "822.Subject" on page 62 of RFC-1327 to read as:
+
+ Mapped to IMPS.Heading.subject. The field-body uses the human-
+ oriented mapping referenceed in Section 3.3.4.
+
+ Modify procedure "IPMS.Heading.subject" on page 71 of RFC-1327 to
+ read as:
+ Mapped to "Subject:". The contents are converted to ASCII or
+ T.61 (Section 3.3.4). Any CRLF are not mapped, but are used as
+ points at which the subject field must be folded.
+
+
+
+
+
+
+
+
+Alvestrand, Kille, Miles, Rose & Thompson [Page 8]
+
+RFC 1495 MHS/RFC-822 Message Body Mapping August 1993
+
+
+5. OID Assignments
+
+ MIME-MHS DEFINITIONS ::= BEGIN
+
+
+ mail OBJECT IDENTIFIER ::= { internet 7 }
+
+ mime-mhs OBJECT IDENTIFIER ::= { mail 1 }
+
+ mime-mhs-headings OBJECT IDENTIFIER ::= { mime-mhs 1 }
+
+ id-hex-partial-message OBJECT IDENTIFIER ::=
+ { mime-mhs-headings 1 }
+
+ id-hex-multipart-message OBJECT IDENTIFIER ::=
+ { mime-mhs-headings 2 }
+
+
+ mime-mhs-bodies OBJECT IDENTIFIER ::= { mime-mhs 2 }
+
+
+ END
+
+6. Security Considerations
+
+ There are no explicit security provisions in this document. However,
+ a warning is in order. This document maps two mechanisms between
+ RFC822 and X.400 that could cause problems. The first is the
+ transfer of binary files. The inherent risks are well known and
+ won't be reiterated here. The second is the propagation of strong
+ content typing. The typing can be used to automatically "launch" or
+ initiate applications against those contents. Any such launching
+ leaves the invoker vulnerable to application-specific viruses; for
+ example, a spreadsheet macro or Postscript command that deletes
+ files. See [2], Section 7.4.2 for a Postscript-specific discussion
+ of this issue.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Alvestrand, Kille, Miles, Rose & Thompson [Page 9]
+
+RFC 1495 MHS/RFC-822 Message Body Mapping August 1993
+
+
+7. Authors' Addresses
+
+ Harald Tveit Alvestrand
+ SINTEF DELAB
+ N-7034 Trondheim
+ NORWAY
+
+ EMail: Harald.Alvestrand@delab.sintef.no
+
+
+ Steve Kille
+ ISODE Consortium
+ P.O. Box 505
+ London
+ SW11 1DX
+ England
+
+ Phone: +44-71-223-4062
+ EMail: S.Kille@ISODE.COM
+
+
+ Robert S. Miles
+ Soft*Switch, Inc.
+ 640 Lee Road
+ Wayne, PA 19087
+
+ Phone: (215) 640-7556
+ EMail: rsm@spyder.ssw.com
+
+
+ Marshall T. Rose
+ Dover Beach Consulting, Inc.
+ 420 Whisman Court
+ Mountain View, CA 94043-2186
+ US
+
+ Phone: +1 415 968 1052
+ Fax: +1 415 968 2510
+ EMail: mrose@dbc.mtview.ca.us
+
+
+ Steven J. Thompson
+ Soft*Switch, Inc.
+ 640 Lee Road
+ Wayne, PA 19087
+
+ Phone: (215) 640-7556
+ EMail: sjt@gateway.ssw.com
+
+
+
+Alvestrand, Kille, Miles, Rose & Thompson [Page 10]
+
+RFC 1495 MHS/RFC-822 Message Body Mapping August 1993
+
+
+8. References
+
+ [1] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, UDEL, August 1982.
+
+ [2] Borenstein, N., and N. Freed, "MIME: Mechanisms for Specifying
+ and Describing the Format of Internet Message Bodies", RFC 1341,
+ Bellcore, Innosoft, June 1992.
+
+ [3] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
+ and RFC-822", RFC 1327, University College London, May 1992.
+
+ [4] Alvestrand, H., and S. Thompson, "Equivalences between 1988 X.400
+ and RFC-822 Message Bodies", RFC 1494, SINTEF DELAB, Soft*Switch,
+ Inc., August 1993.
+
+ [5] Moore, K., "Representation of Non-ASCII Text in Internet Message
+ Headers Message Bodies", RFC 1342, University of Tennesse, June
+ 1992.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Alvestrand, Kille, Miles, Rose & Thompson [Page 11]
+ \ No newline at end of file