Here is my entry to the content-disposition debate.
This memo defines 2 things, which may or may not be a good idea:
- A way to tell the recipient MIME reader which body parts contain only
info that is "about" the other body parts
- A way to tell the recipient MIME reader which is the "main" body part
(and therefore, by extension, that all the others are "attachments").
I have not submitted it as an Internet-Draft; I thought I would solicit
comments off this list first.
The private consultations I have had on this provoked no more than
lukewarm reactions, so I'll see if there are more flames here....
In my (biased) opinion, this makes more sense than
Content-Disposition: {main/attachment}, since it attaches the information
to where it belongs: The composite level.
If there are no significant claims that this does not make any sense,
I'll bother the CNRI about internet-drafting it, and let it stew for a while.
NOTE: This one *has* to be standards-track, because I want other RFCs to
be able to use it.
Please comment!
Harald Tveit Alvestrand
(No, this memo is *NOT* about character sets :-)
draft Multipart/Related May 93
The MIME Multipart/Related content-type
Thu May 20 11:17:05 MET DST 1993
Harald Tveit Alvestrand
SINTEF DELAB
Harald(_dot_)Alvestrand(_at_)delab(_dot_)sintef(_dot_)no
Status of this Memo
This draft document is being circulated for comment.
If consensus is reached it may be submitted to the RFC editor as a
Proposed Standard protocol specificiation, for use with MIME.
Please send comments to the author, or to the 822ext list <ietf-
822(_at_)dimacs(_dot_)rutgers(_dot_)edu>.
The following text is required by the Internet-draft rules:
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its
Areas, and its Working Groups. Note that other groups may also
distribute working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use
Internet Drafts as reference material or to cite them other than
as a "working draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
Alvestrand Expires Nov 20 93 [Page 1]
draft Multipart/Related May 93
1. Introduction
Several applications of MIME, including MIME-PEM and MIME-
Macintosh, have had the need to provide content-types that
provide, basically, two pieces of information:
One, the "basis", which is of a content-type otherwise defined.
One, the "header", which provides interesting information about
the other part of the message. In PEM, this is the algorithm,
signature and key information; in MIME-Macintosh, this is the
Finder information. In both cases, it is possible for the message
to be useful without this part being understood, but there is a
lot of added functionality if this other part is also understood
by the recipient.
In other cases, a desire has been expressed for giving a hint to
the recipient UA on whether it is intended to display the parts of
the message at the same time or as attachments to a main message.
In order to keep the MIME philosophy of having one mechanism to
achieve the same object for different purposes, one single
mechanism should be defined for doing such things.
2. Definition
The following text is copied from RFC 1341, appendix F1.
MIME type name: Multipart
MIME subtype name: Related
Required parameters: None
Optional parameters:
Header=<MIME type>
Mainpart=<Content-ID>
Encoding considerations:
Multipart content-types cannot have encodings.
Security considerations:
Alvestrand Expires Nov 20 93 [Page 2]
draft Multipart/Related May 93
Not considered
Published specification:
This document
3. Intended usage
3.1. The Header= parameter
In cases where the header= parameter is given, the part or parts
with the given type(s) are understood to give information about
the other part or parts of the Multipart.
The placement of the type in the header serves 2 purposes:
- To identify the particular type which has to be treated
specially
- To enable configuration-based UAs to switch to the correct
processing module for that particular header type.
In certain configurations it makes sense to list several "header"
types, for instance when a Macintosh file is sent with a PEM
signature applied to its Data fork (but not to its resource fork).
How to associate each Header with its related Content part must be
defined when defining the Header type; the most common cases will
be that it is only legal to have it together with a single part
not mentioned in the Header= list, or that it applies equally to
all parts not mentioned in the Header= list.
When an UA is able to process the Multipart/Related type, but not
any of the types listed in the Header= parameter, it is allowed
for the UA to suppress the part entirely when viewing the message,
since it does not make much sense to store it separately.
Alvestrand Expires Nov 20 93 [Page 3]
draft Multipart/Related May 93
3.2. The Mainpart= parameter
This parameter is a hint to the recipient UA that the sender
intended the part with the Content-ID of the parameter to be
displayed at once, and that the sender intended that the recipient
should have to take specific action in order to view the other
parts.
One possible implementation of this is to display the main part at
once, and the others as an icon row.
This RFC does not specify where the mainpart should be in the
sequence of parts.
4. Registration forms
Form for registering new parameters to the Content-Type
Multipart/Related type
Parameter:
Parameter value grammar:
Purpose:
Authors' address
Detach and submit to IANA for archiving.
The IETF-822 list is suitable for discussion of such extensions
prior to registration.
5. Example description
Example describing the relationship between a body part mentioned
in a Header= parameter and other body parts in the message
<The example is bogus>
The content-type Application/RecLenList is intended for use
together with the Application/Octet-stream type inside a
Multipart/Related, but can be used with any primitive MIME type.
Alvestrand Expires Nov 20 93 [Page 4]
draft Multipart/Related May 93
In all cases, it refers to the canonical encoding of that type.
The RecLenList consists of a set of INTEGERs in ASCII format, one
per line, and each INTEGER gives the number of octets from the
other body part that should be considered part of this "record".
Multipart/related consideration
The RecLenList applies to only one other body part, so when it is
used in Multipart/Related, there should only be one body part
present that is not mentioned in a Header= parameter.
6. Security considerations
No security considerations relevant to this memo have been
identified.
7. Acknowledgments
Acknowledgements are, as always, due to more people than can be
listed. However, I especially want to thank:
- Nathaniel Borenstein and Ned Freed, for writing the MIME that
I can base this on
- Ned Freed and Patrik Faltstrom (diaeresis on the a end o in
his last name), for trying to define the MIME body parts that
led me to write this memo
- SAS catering, who provided the service during the airplane
trip during which the first version of this document was
composed.
8. References
RFC 1341 - MIME
RFC 1421 - PEM
Alvestrand Expires Nov 20 93 [Page 5]
draft Multipart/Related May 93
9. Author's address
Harald Tveit Alvestrand
SINTEF DELAB
N-7034 Trondheim
NORWAY
+47 7 59 70 94
Harald(_dot_)T(_dot_)Alvestrand(_at_)delab(_dot_)sintef(_dot_)no
Alvestrand Expires Nov 20 93 [Page 6]