The MIME Multipart/Related Content-type
obsoleted by
- rfc-2387 — The MIME Multipart/Related Content-type
obsoletes
- rfc-1872 — The MIME Multipart/Related Content-type
Extracted elements (20)
Content-Disposition headers are included within Multipart/Related entities to provide presentation information to User Agents that do not recognize Multipart/Related — they will treat the multipart as Multipart/Mixed and may find the Content-Disposition information useful. However, for aware UAs the disposition type is redundant or misleading.
MUAs that use configuration mechanisms are suggested to refer to Multipart/Related as Multipart/Related/<type> (where <type> is the value of the type parameter) to allow type-specific configuration.
The Multipart/Related type was created to provide a single, unified mechanism for compound objects rather than defining specific multipart subtypes for each new object type (as had been done for MIME-PEM, MIME-Macintosh, etc.), in keeping with the MIME philosophy of one mechanism for the same goal.
The 'start-info' parameter distinguishes a content-ID reference from a token or quoted-string by whether the first non-white-space character is '<'; applications that use Multipart/Related must specify the interpretation of start-info.
This document obsoletes RFC 1872. User Agents that do not recognize Multipart/Related will treat it as Multipart/Mixed, providing a graceful degradation path for non-aware agents.
MIME-capable MUAs are required to provide the application: (a) the bodies of MIME entities and Content-* headers, (b) the Multipart/Related Content-type header parameters, and (c) the correspondence between each body's local file name, header data, and content-ID.
MIME User Agents that 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.
The type parameter must be specified and its value is the MIME media type of the root 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.
User Agents shall provide the start-info parameter's value to the processing application.
User agents that do not recognize Multipart/Related shall, in accordance with [MIME], treat the entire entity as Multipart/Mixed.
User Agents that understand Multipart/Related shall ignore the Content-Disposition header's disposition type within a Multipart/Related body part, as the application processing the compound object determines the presentation style.
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 'cid:' URI scheme can be used within compound object body parts to reference other body parts by their Content-ID, as illustrated in the Text/X-Okie example where image body parts are referenced internally via 'cid:' URIs.
The Multipart/Related content-type provides a mechanism for representing compound objects consisting of several inter-related MIME body parts where proper display cannot be achieved by individually displaying constituent parts. The content-type of the object is specified by the required 'type' parameter.
The 'start-info' parameter provides additional information to an application; it contains either a string or points via a content-ID to another MIME entity. A leading '<' character distinguishes a content-ID reference from a token or quoted-string.
The 'start' parameter, if given, is the content-ID of the compound object's root body part. If not present, the root is the first body part in the Multipart/Related entity.
The 'type' parameter is required 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.
This document registers the Multipart/Related media type with IANA. Required parameters: Type (a media type/subtype). Optional parameters: Start, Start-info. Multipart content-types cannot have encodings.
Security considerations relevant to Multipart/Related are identical to those of the underlying content-type; the content-type itself introduces no additional security considerations beyond those of the referenced type.
The Multipart/Related parameter syntax is defined as: related-param := [';' 'start' '=' cid] [';' 'start-info' '=' (cid-list / value)] [';' 'type' '=' type '/' subtype], where order is independent. cid is defined as msg-id per RFC 822.