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/rfc2387.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc2387.txt (limited to 'doc/rfc/rfc2387.txt') diff --git a/doc/rfc/rfc2387.txt b/doc/rfc/rfc2387.txt new file mode 100644 index 0000000..b8e5f6f --- /dev/null +++ b/doc/rfc/rfc2387.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group E. Levinson +Request for Comments: 2387 August 1998 +Obsoletes: 2112 +Category: Standards Track + + + The MIME Multipart/Related Content-type + +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. + +Abstract + + The Multipart/Related content-type provides a common mechanism for + representing objects that are aggregates of related MIME body parts. + This document defines the Multipart/Related content-type and provides + examples of its use. + +1. Introduction + + Several applications of MIME, including MIME-PEM, and MIME-Macintosh + and other proposals, require multiple body parts that make sense only + in the aggregate. The present approach to these compound objects has + been to define specific multipart subtypes for each new object. In + keeping with the MIME philosophy of having one mechanism to achieve + the same goal for different purposes, this document describes a + single mechanism for such aggregate or compound objects. + + The Multipart/Related content-type addresses the MIME representation + of compound objects. The object is categorized by a "type" + parameter. Additional parameters are provided to indicate a specific + starting body part or root and auxiliary information which may be + required when unpacking or processing the object. + + Multipart/Related MIME entities may contain Content-Disposition + headers that provide suggestions for the storage and display of a + body part. Multipart/Related processing takes precedence over + Content-Disposition; the interaction between them is discussed in + section 4. + + + +Levinson Standards Track [Page 1] + +RFC 2387 Multipart/Related August 1998 + + + Responsibility for the display or processing of a Multipart/Related's + constituent entities rests with the application that handles the + compound object. + +2. Multipart/Related Registration Information + + The following form is copied from RFC 1590, Appendix A. + + To: IANA@isi.edu + Subject: Registration of new Media Type content-type/subtype + + Media Type name: Multipart + + Media subtype name: Related + + Required parameters: Type, a media type/subtype. + + Optional parameters: Start + Start-info + + Encoding considerations: Multipart content-types cannot have + encodings. + + Security considerations: Depends solely on the referenced type. + + Published specification: RFC-REL (this document). + + Person & email address to contact for further information: + Edward Levinson + 47 Clive Street + Metuchen, NJ 08840-1060 + +1 908 494 1606 + XIson@cnj.digex.net + +3. Intended usage + + The Multipart/Related media type is intended for compound objects + consisting of several inter-related body parts. For a + Multipart/Related object, proper display cannot be achieved by + individually displaying the constituent body parts. The content-type + of the Multipart/Related object is specified by the type parameter. + The "start" parameter, if given, points, via a content-ID, to the + body part that contains the object root. The default root is the + first body part within the Multipart/Related body. + + The relationships among the body parts of a compound object + distinguishes it from other object types. These relationships are + often represented by links internal to the object's components that + + + +Levinson Standards Track [Page 2] + +RFC 2387 Multipart/Related August 1998 + + + reference the other components. Within a single operating + environment the links are often file names, such links may be + represented within a MIME message using content-IDs or the value of + some other "Content-" headers. + +3.1. The Type Parameter + + The type parameter must be specified and its value is the MIME media + type of the "root" body part. It permits a MIME user agent to + determine the content-type without reference to the enclosed body + part. If the value of the type parameter and the root body part's + content-type differ then the User Agent's behavior is undefined. + +3.2. The Start Parameter + + The start parameter, if given, is the content-ID of the compound + object's "root". If not present the "root" is the first body part in + the Multipart/Related entity. The "root" is the element the + applications processes first. + +3.3. The Start-Info Parameter + + Additional information can be provided to an application by the + start-info parameter. It contains either a string or points, via a + content-ID, to another MIME entity in the message. A typical use + might be to provide additional command line parameters or a MIME + entity giving auxiliary information for processing the compound + object. + + Applications that use Multipart/Related must specify the + interpretation of start-info. User Agents shall provide the + parameter's value to the processing application. Processes can + distinguish a start-info reference from a token or quoted-string by + examining the first non-white-space character, "<" indicates a + reference. + +3.4. Syntax + + related-param := [ ";" "start" "=" cid ] + [ ";" "start-info" "=" + ( cid-list / value ) ] + [ ";" "type" "=" type "/" subtype ] + ; order independent + + cid-list := cid cid-list + + cid := msg-id ; c.f. [822] + + + + +Levinson Standards Track [Page 3] + +RFC 2387 Multipart/Related August 1998 + + + value := token / quoted-string ; c.f. [MIME] + ; value cannot begin with "<" + + Note that the parameter values will usually require quoting. Msg-id + contains the special characters "<", ">", "@", and perhaps other + special characters. If msg-id contains quoted-strings, those quote + marks must be escaped. Similarly, the type parameter contains the + special character "/". + +4. Handling Content-Disposition Headers + + Content-Disposition Headers [DISP] suggest presentation styles for + MIME body parts. [DISP] describes two presentation styles, called + the disposition type, INLINE and ATTACHMENT. These, used within a + multipart entity, allow the sender to suggest presentation + information. [DISP] also provides for an optional storage (file) + name. Content-Disposition headers could appear in one or more body + parts contained within a Multipart/Related entity. + + Using Content-Disposition headers in addition to Multipart/Related + provides presentation information to User Agents that do not + recognize Multipart/Related. They will treat the multipart as + Multipart/Mixed and they may find the Content-Disposition information + useful. + + With Multipart/Related however, the application processing the + compound object determines the presentation style for all the + contained parts. In that context the Content-Disposition header + information is redundant or even misleading. Hence, User Agents that + understand Multipart/Related shall ignore the disposition type within + a Multipart/Related body part. + + It may be possible for a User Agent capable of handling both + Multipart/Related and Content-Disposition headers to provide the + invoked application the Content-Disposition header's optional + filename parameter to the Multipart/Related. The use of that + information will depend on the specific application and should be + specified when describing the handling of the corresponding compound + object. Such descriptions would be appropriate in an RFC registering + that object's media type. + +5. Examples + +5.1 Application/X-FixedRecord + + The X-FixedRecord content-type consists of one or more octet-streams + and a list of the lengths of each record. The root, which lists the + record lengths of each record within the streams. The record length + + + +Levinson Standards Track [Page 4] + +RFC 2387 Multipart/Related August 1998 + + + list, type Application/X-FixedRecord, consists of a set of INTEGERs + in ASCII format, one per line. Each INTEGER gives the number of + octets from the octet-stream body part that constitute the next + "record". + + The example below, uses a single data block. + + Content-Type: Multipart/Related; boundary=example-1 + start="<950120.aaCC@XIson.com>"; + type="Application/X-FixedRecord" + start-info="-o ps" + + --example-1 + Content-Type: Application/X-FixedRecord + Content-ID: <950120.aaCC@XIson.com> + + 25 + 10 + 34 + 10 + 25 + 21 + 26 + 10 + --example-1 + Content-Type: Application/octet-stream + Content-Description: The fixed length records + Content-Transfer-Encoding: base64 + Content-ID: <950120.aaCB@XIson.com> + + T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS + BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk + IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS + BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1 + YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW + NrIHF1YWNrCkUgSSBFIEkgTwo= + + --example-1-- + + + + + + + + + + + + + +Levinson Standards Track [Page 5] + +RFC 2387 Multipart/Related August 1998 + + +5.2 Text/X-Okie + + The Text/X-Okie is an invented markup language permitting the + inclusion of images with text. A feature of this example is the + inclusion of two additional body parts, both picture. They are + referred to internally by the encapsulated document via each + picture's body part content-ID. Usage of "cid:", as in this example, + may be useful for a variety of compound objects. It is not, however, + a part of the Multipart/Related specification. + + Content-Type: Multipart/Related; boundary=example-2; + start="<950118.AEBH@XIson.com>" + type="Text/x-Okie" + + --example-2 + Content-Type: Text/x-Okie; charset=iso-8859-1; + declaration="<950118.AEB0@XIson.com>" + Content-ID: <950118.AEBH@XIson.com> + Content-Description: Document + + {doc} + This picture was taken by an automatic camera mounted ... + {image file=cid:950118.AECB@XIson.com} + {para} + Now this is an enlargement of the area ... + {image file=cid:950118:AFDH@XIson.com} + {/doc} + --example-2 + Content-Type: image/jpeg + Content-ID: <950118.AFDH@XIson.com> + Content-Transfer-Encoding: BASE64 + Content-Description: Picture A + + [encoded jpeg image] + --example-2 + Content-Type: image/jpeg + Content-ID: <950118.AECB@XIson.com> + Content-Transfer-Encoding: BASE64 + Content-Description: Picture B + + [encoded jpeg image] + --example-2-- + +5.3 Content-Disposition + + In the above example each image body part could also have a Content- + Disposition header. For example, + + + + +Levinson Standards Track [Page 6] + +RFC 2387 Multipart/Related August 1998 + + + --example-2 + Content-Type: image/jpeg + Content-ID: <950118.AECB@XIson.com> + Content-Transfer-Encoding: BASE64 + Content-Description: Picture B + Content-Disposition: INLINE + + [encoded jpeg image] + --example-2-- + + User Agents that recognize Multipart/Related will ignore the + Content-Disposition header's disposition type. Other User Agents + will process the Multipart/Related as Multipart/Mixed and may make + use of that header's information. + +6. User Agent Requirements + + User agents that do not recognize Multipart/Related shall, in + accordance with [MIME], treat the entire entity as Multipart/Mixed. + MIME User Agents that do recognize Multipart/Related entities but are + unable to process the given type should give the user the option of + suppressing the entire Multipart/Related body part shall be. + + Existing MIME-capable mail user agents (MUAs) handle the existing + media types in a straightforward manner. For discrete media types + (e.g. text, image, etc.) the body of the entity can be directly + passed to a display process. Similarly the existing composite + subtypes can be reduced to handing one or more discrete types. + Handling Multipart/Related differs in that processing cannot be + reduced to handling the individual entities. + + The following sections discuss what information the processing + application requires. + + It is possible that an application specific "receiving agent" will + manipulate the entities for display prior to invoking actual + application process. Okie, above, is an example of this; it may need + a receiving agent to parse the document and substitute local file + names for the originator's file names. Other applications may just + require a table showing the correspondence between the local file + names and the originator's. The receiving agent takes responsibility + for such processing. + +6.1 Data Requirements + + MIME-capable mail user agents (MUAs) are required to provide the + application: + + + + +Levinson Standards Track [Page 7] + +RFC 2387 Multipart/Related August 1998 + + + (a) the bodies of the MIME entities and the entity Content-* headers, + + (b) the parameters of the Multipart/Related Content-type header, and + + (c) the correspondence between each body's local file name, that + body's header data, and, if present, the body part's content-ID. + +6.2 Storing Multipart/Related Entities + + The Multipart/Related media type will be used for objects that have + internal linkages between the body parts. When the objects are + stored the linkages may require processing by the application or its + receiving agent. + +6.3 Recursion + + MIME is a recursive structure. Hence one must expect a + Multipart/Related entity to contain other Multipart/Related entities. + When a Multipart/Related entity is being processed for display or + storage, any enclosed Multipart/Related entities shall be processed + as though they were being stored. + +6.4 Configuration Considerations + + It is suggested that MUAs that use configuration mechanisms, see + [CFG] for an example, refer to Multipart/Related as Multi- + part/Related/, were is the value of the "type" + parameter. + +7. Security Considerations + + Security considerations relevant to Multipart/Related are identical + to those of the underlying content-type. + +8. Acknowledgments + + This proposal is the result of conversations the author has had with + many people. In particular, Harald A. Alvestrand, James Clark, + Charles Goldfarb, Gary Houston, Ned Freed, Ray Moody, and Don + Stinchfield, provided both encouragement and invaluable help. The + author, however, take full responsibility for all errors contained in + this document. + + + + + + + + + +Levinson Standards Track [Page 8] + +RFC 2387 Multipart/Related August 1998 + + +9. References + + [822] Crocker, D., "Standard for the Format of ARPA Internet + Text Messages", STD 11, RFC 822, August 1982. + + [CID] Levinson, E., and J. Clark, "Message/External-Body + Content-ID Access Type", RFC 1873, December 1995, + Levinson, E., "Message/External-Body Content-ID Access + Type", Work in Progress. + + [CFG] Borenstein, N., "A User Agent Configuration Mechanism For + Multimedia Mail Format Information", RFC 1524, September + 1993. + + [DISP] Troost, R., and S. Dorner, "Communicating Presentation + Information in Internet Messages: The Content- + Disposition Header", RFC 1806, June 1995. + + [MIME] Borenstein, N., and Freed, N., "Multipurpose Internet + Mail Extensions (MIME) Part One: Format of Internet + Message Bodies", RFC 2045, November 1996. + +9. Author's Address + + Edward Levinson + 47 Clive Street + Metuchen, NJ 08840-1060 + USA + + Phone: +1 908 494 1606 + EMail: XIson@cnj.digex.com + +10. Changes from previous draft (RFC 2112) + + Corrected cid urls to conform to RFC 2111; the angle brackets were + removed. + + + + + + + + + + + + + + + +Levinson Standards Track [Page 9] + +RFC 2387 Multipart/Related August 1998 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Levinson Standards Track [Page 10] + -- cgit v1.2.3