From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1495.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc1495.txt (limited to 'doc/rfc/rfc1495.txt') 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: + . + +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 -- cgit v1.2.3