RFC 1872

The MIME Multipart/Related Content-type 💖

okay bestie, here's the tea on this RFC 🎀

• Network Working Group 🌸
• RFC number: 1872
• Author: E. Levinson, Accurate Information Systems, Inc. 🧑‍💻
• Category: Experimental 🧪
• Date: December 1995 📅
• Obsoletes / Updates: the title block doesn't list anything this one obsoletes or updates ✨

Status of This Memo ✨

this memo defines an Experimental Protocol for the Internet community 🧪. it does not specify an Internet standard of any kind, so don't go treating it like one 💅. discussion and suggestions for improvement are requested, so share your thoughts 🗣️. distribution of this memo is unlimited 🌈.

Abstract 🦋

the Multipart/Related content-type gives you a common way to represent objects that are bundles of related MIME body parts 🎁. this document defines the Multipart/Related content-type and shows examples of how to use it ✨.

1. Introduction 🌸

several MIME applications, including MIME-PEM, MIME-Macintosh, and other proposals, need multiple body parts that only make sense together 🫶. the old approach was to define a brand-new multipart subtype for every single compound object. but MIME is all about having one mechanism for the same goal across different purposes, so this document describes a single mechanism for these aggregate or compound objects 💜.

the Multipart/Related content-type covers the MIME representation of compound objects 💅. the object is categorized by a "type" parameter. there are extra parameters for pointing at a specific starting body part (the root) and for auxiliary info that might be needed when unpacking or processing the object 🧚.

responsibility for displaying or processing 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. yes, it's a whole email form, very 90s 💀

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, a content-id.
                           Start-info, a string or content-id list.

Encoding considerations:   Multipart content-types cannot have
                           encodings.

Security considerations:   Depends solely on the referenced type.

Published specification:   This document.

Person & email address to contact for further information:
                           Edward Levinson
                           Accurate Information Systems, Inc.
                           2 Industrial Way
                           Eatontown, NJ 07724
                           +1 908 389 5550
                           +1 908 389 5556 (fax)
                           ELevinson@Accurate.com

3. Intended usage 🧩

the Multipart/Related media type is for compound objects made up of several inter-related body parts 🔗. for a Multipart/Related object, proper display can't be achieved by displaying each constituent body part on its own 🙈. 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 🥇.

what makes a compound object its own thing is the relationships among its body parts 🕸️. these relationships are often represented by links inside the object's components that reference the other components. within a single operating environment, the links are often file names, and those links may be represented within a MIME message using content-IDs or the value of some other "Content-" header 🔗.

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 lets a MIME user agent figure out the content-type without looking at the enclosed body part. if the value of the type parameter and the root body part's content-type differ, the User Agent's behavior is undefined 🌀.

Note: restricting the "type" parameter's value to an existing media type lets the right processing be identified without creating yet another hierarchy of registered types 🙌. a possible default action would be for the MIME mail User Agent (MUA) to display the "start" entity alone when it can process the media type as a basic type but not as Multipart/Related 📨.

3.2. The Start Parameter 🥇

the start parameter, if given, is the content-ID of the compound object's root. if it's not present, the root is the first body part in the Multipart/Related entity. the root is the element the application processes first 🚀.

in the case of a Multipart/Alternative body part containing several entities with identical content-IDs, the start entity should be selected using the Multipart/Alternative rules 🎭.

Note: the "start" parameter allows for types where the root element gets generated by the sending application, maybe on the fly ⚡. such an application can create the "start" content-id when processing begins, then insert the body part once it's complete 🧵.

3.3. The Start-Info Parameter 📝

extra info can be handed to an application through 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 is 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 tell a start-info reference apart from a token or quoted-string by checking the first non-white-space character: "<" indicates a content-id 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]

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. Examples 📚

4.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 is the one that lists the record lengths of each record within the streams. the record length 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, which the sender processes on the fly to generate the record length list. so the list shows up after the data 🫧.

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/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
Content-Type: Application/X-FixedRecord
Content-ID: <950120.aaCC@XIson.com>

25
10
34
10
25
21
26
10
--example-1--

4.2 Text/X-Okie 🖼️

Text/X-Okie is an invented markup language (kinda like HTML 💅) that lets you include images with text. the big thing to notice here is that there are two extra body parts, both pictures 📸. the document refers to them internally via each picture's body part content-ID. using "cid:", like this example does, might be useful for a variety of compound objects 🌈, but it is not part of the Multipart/Related specification, so don't count it as part of that spec.

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-1--

heads up 👀 the closing delimiter in this example says --example-1-- even though the boundary is example-2. that's exactly how the original prints it, so the code block keeps it as-is.

5. User Agent Requirements 🛡️

user agents that don't recognize Multipart/Related shall, in accordance with [MIME], treat the entire entity as Multipart/Mixed 🤷‍♀️. MIME User Agents that recognize Multipart/Related entities but can't process the given type shall either suppress the entire Multipart/Related body part or process the root alone. either way, the user should be notified of what the MUA did 📣.

handling Multipart/Related is different from other media types, since processing can't be reduced to handling the individual entities 🧩. existing media types are handled by MIME-capable MUAs in a straightforward way. for basic media types (e.g., text, image, etc.), the body of the entity can be passed straight to a display process 🖥️. composite media types can be reduced to handing off one or more discrete types 🍰.

Multipart/Related provides an irreducible composite media type 💎.

the following sections discuss what information the processing application requires 📋.

it's possible that an application-specific "receiving agent" will manipulate the entities after the MIME User Agent's initial processing, but before the actual application process is invoked 🧑‍💻. from the MUA's point of view, the receiving agent is the application. Okie, above, shows this: it may need a receiving agent to parse the document and swap in local file names for the originator's file names 🗂️. other applications may just need a table showing the correspondence between the local file names and the originator's.

the receiving agent takes responsibility for any such processing 🫡.

5.1 Data Requirements 📦

MIME-capable MUAs are required to provide the application:

• (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.

5.2. Storing Multipart/Related Entities

okay so Multipart/Related is for objects whose body parts are linked to each other internally 🔗 When you store one of these, those linkages might need processing by the application or its receiving agent 🧚

5.3. Recursion

MIME is recursive 🌀 so you have to 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. The app handling the outermost Multipart/Related shall be responsible for making sure the embedded ones get handled properly 👑 main character energy for the outermost layer, fr

5.5. Configuration Considerations

It's suggested that MUAs that use configuration mechanisms (see [CFG] for an example) refer to Multipart/Related as Multipart/Related/<type>, where <type> is the value of the "type" parameter 🎀

6. Security Considerations ✨

Security considerations relevant to Multipart/Related are identical to those of the underlying content-type. So no extra drama here, the security story is the same as the underlying type's 🔥

7. Acknowledgments 🫶

This proposal is the result of conversations the author has had with many people 💖 In particular, similar work was described by Harald A. Alvestrand (early drafts of Multipart/Related), Dave Crocker (Multipart/Families), and Keith Moore (Multipart/References). Also, James Clark, Charles Goldfarb, Gary Houston, Ned Freed, Ray Moody, and Don Stinchfield provided both encouragement and invaluable help 🌸 The author, however, takes full responsibility for all errors contained in this document 💅

8. References 📚

• [822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982.
• [CFG] Borenstein, N., "A User Agent Configuration Mechanism For Multimedia Mail Format Information", RFC 1524, Bellcore, September 1993.
• [MIME] Borenstein, N. and and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September 1993.

9. Author's Address 💌

Edward Levinson Accurate Information Systems, Inc. 2 Industrial Way Eatontown, NJ 07724-2265 USA

Phone: +1 908 389 5550 EMail: ELevinson@Accurate.com