Separate disposition from application handling
04Content-Disposition suggests inline or attachment presentation. A compound-object application has a different responsibility.
A third agent recognizes the related container but cannot process its declared root type. Section 6 recommends offering the user suppression of the entire related body part. This differs from not recognizing Multipart/Related at all.
Source for this drawing: RFC 2387 · Read RFC section 4 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
An agent that understands Multipart/Related shall ignore each contained part’s disposition type; the compound application determines presentation.
- An agent that understands Multipart/Related shall ignore each contained part’s disposition type; the compound application determines presentation.
- An optional filename may be supplied to the application, whose defined behavior determines its use. Ignoring the disposition type does not require discarding every header parameter.
- An agent that does not recognize Multipart/Related treats it as Multipart/Mixed and may use disposition hints. An agent that recognizes it but cannot process the given type should offer suppression of the whole related body part.
Fictional .example identifiers and omitted payloads. These are simplified illustrations, not complete importable messages or a full MIME parser.
Read the RFC section ↗