Hi-
After much delay, here is the (rough) draft for the
Content-Disposition header. Please tear into this and let me know what
you think! Special thanks to Keith Moore for his excellent suggestions.
-Rens
Network Working Group J. Laurens Troost
Internet Draft: Content-Disposition
rens(_at_)century(_dot_)com
June 1993
Communicating Presentational information in Multi - Part Internet
Messages:The Content-Disposition Header.
Status of this Memo:
This draft document will be submitted to the Internet Activities Board
as a standards document. As this is a working document only, it
should neither be cited nor quoted in any formal document.
Distribution of this memo is unlimited. Please send comments to ietf-
822(_at_)dimacs(_dot_)rutgers(_dot_)edu(_dot_)
Abstract:
This memo provides a mechanism whereby messages conforming to
the RFC 1341 ("MIME") specification for multipart message format can
convey presentational information for each of their body parts. It
specifies a new "Content-disposition" header, optional and valid for
any RFC 1341 "body part". Values which correspond to common usage
in electronic mail today are supplied, as are procedures for extending
this set of values. Mechanisms are provided for the sender to suggest
a filename for bodypart storage and to indicate inter-bodypart
relationships and dependencies.
This document is intended as an extension to RFC 1341. As such, the
reader is assumed to be familiar with RFC 1341, RFC 1342, and RFC
822. The information presented herein supplements but does not
replace that found in those documents.
1. Introduction
RFC 1341 describes a standard format for encapsulating multiple
pieces of heterogeneous data into a single Internet message. That
document does not address the issue of presentation styles, except to
suggest that compound document formats might use the "Content-ID"
header to reference and connect multiple related body parts; it
provides a framework for the interchange of message content, but
leaves presentation issues solely in the hands of mail user agent
(MUA) implementors.
Common usage distinguishes between two different ways of
presenting multipart electronic messages; as a main document with a
list of separate attachments, and as a single document with the
various parts expanded (displayed) inline. The display of an
attachment is generally construed to require positive action on the
part of the recipient, while inline message components are displayed
automatically when the message is viewed. A mechanism is needed to
allow the sender to transmit this sort of presentational information to
the recipient; the Content-Disposition header provides this mechanism,
allowing each component of a message to be tagged with an indication
of its desired presentation semantics.
Tagging messages in this manner will often be sufficient for basic
message formatting. However, in many cases a more powerful and
flexible approach will be necessary. One likely approach is the use of a
compound document, which can be defined as a message component
that references other components and organizes them in a
sophisticated way. When the MUA displays the compound document,
these various subsidiary components are also displayed.
If a subsidiary bodypart is to be displayed during the processing of a
compound document, the MUA must know to avoid displaying it
during MIME parsing. Otherwise, a bodypart might easily be displayed
or processed multiple times, which depending on the context could be
simply annoying or a serious error. The disposition type 'hidden' is
provided to indicate that a bodypart is referenced elsewhere in the
message, and that processing shold not be attempted by the MIME
parser. The 'owner' parameter is defined to indicate the bodypart(s)
which refer to the hidden entity.
In addition to allowing the sender to specify the presentational
disposition of a message component, it is desirable to allow her to
indicate a default archival disposition; a filename. The optional
"filename" parameter provides for this.
2. The Content-disposition Header Field:
Since it makes no sense to say that an entire message is an
attachment, or that it is displayed elsewhere and should be hidden,
the Content-Disposition header should not be used in the context of an
entire message. Composing agents must only mark body parts with a
Content-Disposition, and receiving agents should ignore any
occurrence of this field in the top-level header of a message.
Content-Disposition is an optional header; In it's absence, presentation
should default to 'inline'. This is compatible with the behavior of
current MIME-aware user agents. Alternatively, the user might be
allowed to specify the default behavior.
It is desirable to keep the set of possible disposition types small and
well defined, to avoid needless complexity. Indeed, it is hoped that
complex presentation schemes will be delegated to compound
document display applications, as discussed below. Evolving usage
may, however, require the definition of additional disposition types
or parameters, so the set of disposition values is extensible. New
values should be registered with the IANA, in the manner specified in
RFC 1341, appendix E.
In the extended BNF notation of [RFC 822], the Content-Disposition
header field is defined as follows:
disposition := "Content-Disposition" ":" type *(";" parms)
; case-insensitive matching of type
type := "inline" / "attachment" / "hidden" / extension-token
; all type values are case-insensitive
parms := owner-parm / requires-parm /filename-parm / extension-parm
owner-parm := "owner" "=" content-id *(","content-id)
requires-parm := "requires" "=" content-id *(","content-id)
filename-parm := "filename" "=" filename;
2.1 The Inline Disposition Type
A bodypart should be marked 'inline' if it is intended to be displayed
automatically upon display of the message. Inline bodyparts should be
displayed in the order in which they are encountered.
2.2 The Attachment Disposition Type.
Bodyparts can be designated 'attachment' to indicate that they are
separate from the main body of the mail message, and that their
display should not be automatic, but contingent upon some further
action of the user. The MUA might instead present the user of a
bitmap terminal with an iconic representation of the attachments, or,
on character terminals, with a list of attachments from which the user
could select for viewing or storage.
2.3 The Hidden Disposition Type and the Owner Parameter
Display semantics can get much more complicated than our basic
inline/attachment dichotomy can model. Truly sophisticated
multipart document formatting can be accomplished by the
development and registration of compound documents as subtypes of
application, as defined in [RFC 1341].
If this approach is used, it is possible that the display of a given
bodypart (the compound document) will entail the display of one or
more others. This presents a problem; subsidiary bodyparts should
not be displayed during MIME parsing, since this would result in an
item being displayed twice.
Such subsidiary bodyparts should be tagged with the content-
disposition 'hidden', which indicates to the MIME parser that display
of the bodypart in question should not be necessary. The parameter
'owner' should indicate the bodypart(s) which display or otherwise
use the bodypart thus tagged. If the MUA is capable of displaying the
former, it should not also attempt to display the latter. Should display
of all owners for a 'hidden' bodypart prove impossible, the
'attachment' model should be used as a fallback.
It is an error to use the 'hidden' disposition type without an 'owner'
parameter.
2.4 The Requires Parameter.
It is useful for the recipient MUA to know before attempting to
display a bodypart that this action will require the display or
processing of one or more other bodyparts. Thus armed, an MUA can
warn the user if desired information is unavailable, pre-fetch any
needed external information, or do any required processing.
The optional 'requires' parameter should be used to indicate that the
tagged bodypart internally references one or more other bodyparts.
The value of this parameter should be a comma - delimited list of the
Content-IDs of the bodyparts thus referenced.
2.5 The Filename Parameter.
The sender may want to indicate a default filename to be used for
detaching and storing a bodypart. The filename must be US-ASCII, in
order to ensure interoperability over the greatest number of systems.
Although not a requirement, implementors should attempt to keep
filenames to less than eleven characters, as some systems are limited
in this regard.
3 Examples
4 Summary
o Content-Disposition takes one of three values, 'inline',
'attachment', and 'hidden'.
o In the absence of a Content-Disposition header, the default
interpretation should be 'inline'.
o Use the 'hidden' designation for a bodypart that is referenced
by other bodyparts. When using 'hidden', enumerate the
referencing bodyparts with the 'owner' parameter.
o Use the 'requires' parameter to indicate that a bodypart
references other bodyparts internally.
o Use the 'filename' parameter to suggest a filename for storing
the bodypart.
5. Security Considerations:
Security considerations are not discussed in this memo.
Author's Address:
J. Laurens Troost
New Century Systems
New York, New York
rens(_at_)century(_dot_)com