The MIME Multipart/Related Content-type
obsoletes
- rfc-2112 — The MIME Multipart/Related Content-type
Extracted elements (21)
A 'receiving agent' concept is introduced to allow application-specific preprocessing of entities before invocation of the actual application process; for example, substituting local file names for originator file names in internal links.
Content-Disposition headers are intentionally ignored within Multipart/Related because the processing application controls presentation of all parts; however, they are still useful for User Agents that fall back to treating the entity as Multipart/Mixed.
The Multipart/Related type was created to replace the ad-hoc approach of defining specific multipart subtypes for each new compound object (e.g., MIME-PEM, MIME-Macintosh), providing a single mechanism in keeping with MIME's philosophy of one mechanism for the same goal across different purposes.
The type parameter is required to permit a MIME user agent to determine the content-type without having to examine the enclosed root body part, enabling early processing decisions.
RFC 2387 corrected cid URLs from RFC 2112 to conform to RFC 2111 by removing the angle brackets from cid URLs.
It is suggested that MUAs using configuration mechanisms refer to Multipart/Related as 'Multipart/Related/<type>' where <type> is the value of the type parameter, to allow type-specific configuration.
Multipart/Related content-types cannot have encodings. User Agents that do not recognize Multipart/Related will treat it as Multipart/Mixed, so including Content-Disposition headers can provide useful presentation information to those agents.
The use of 'cid:' URI references within body parts to reference other body parts (as shown in the Text/X-Okie example) may be useful for compound objects but is not itself part of the Multipart/Related specification.
MIME-capable MUAs are required to provide the processing application: (a) the bodies and Content-* headers of MIME entities, (b) the parameters of the Multipart/Related Content-type header, and (c) the correspondence between each body's local file name, header data, and content-ID.
MIME User Agents that recognize Multipart/Related 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; its value is the MIME media type of the root body part.
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 disposition type within a Multipart/Related body part, since the processing application determines the presentation style for all contained parts.
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 (recursion handling).
Multipart/Related is a MIME content-type for compound objects consisting of inter-related body parts that cannot be properly displayed by individually presenting their constituent parts. The content-type of the compound object is specified by the required 'type' parameter.
The 'start-info' parameter provides additional information to the processing application, containing either a string or a content-ID reference (indicated by a leading '<') to another MIME entity in the message. Applications using Multipart/Related must specify the interpretation of start-info.
The 'start' parameter, if present, is the content-ID of the compound object's root body part. If absent, the root defaults to the first body part in the Multipart/Related entity. The root is the element the application processes first.
The 'type' parameter is required and specifies the MIME media type of the root body part, allowing a user agent to determine the content-type without examining the enclosed body part. If the type parameter value differs from the root body part's content-type, UA behavior is undefined.
Security considerations relevant to Multipart/Related are identical to those of the underlying content-type; no additional security considerations are introduced by the Multipart/Related wrapper itself.
The Multipart/Related parameter syntax is: related-param := [';' 'start' '=' cid] [';' 'start-info' '=' (cid-list / value)] [';' 'type' '=' type '/' subtype], where cid is an RFC 822 msg-id and parameters are order-independent. Parameter values usually require quoting due to special characters.