Network Working Group R. Troost
Request for Comments: 2183 New Century Systems
Updates: 1806 S. Dorner
Category: Standards Track QUALCOMM Incorporated
K. Moore, Editor
University of Tennessee
Communicating Presentation Information in
The Content-Disposition Header Field
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
This memo provides a mechanism whereby messages conforming to the
MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC
2049] can convey presentational information. It specifies the
"Content-Disposition" header field, which is optional and valid for
any MIME entity ("message" or "body part"). Two values for this
header field are described in this memo; one for the ordinary linear
presentation of the body part, and another to facilitate the use of
mail to transfer files. It is expected that more values will be
defined in the future, and procedures are defined for extending this
set of values.
This document is intended as an extension to MIME. As such, the
reader is assumed to be familiar with the MIME specifications, and
[RFC 822]. The information presented herein supplements but does not
replace that found in those documents.
This document is a revision to the Experimental protocol defined in
RFC 1806. As compared to RFC 1806, this document contains minor
editorial updates, adds new parameters needed to support the File
Transfer Body Part, and references a separate specification for the
handling of non-ASCII and/or very long parameter values.
Troost, et. al. Standards Track [Page 1]
RFC 2183 Content-Disposition August 1997
MIME specifies a standard format for encapsulating multiple pieces of
data into a single Internet message. That document does not address
the issue of presentation styles; it provides a framework for the
interchange of message content, but leaves presentation issues solely
in the hands of mail user agent (MUA) implementors.
Two common ways of presenting multipart electronic messages are 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. The definition of such
approaches is beyond the scope of this memo; however, such approaches
can benefit from additional Content-Disposition values and
parameters, to be defined at a later date.
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. Further, the creation-date,
modification-date, and read-date parameters allow preservation of
those file attributes when the file is transmitted over MIME email.
NB: The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC 2119].
2. The Content-Disposition Header Field
Content-Disposition is an optional header field. In its absence, the
MUA may use whatever presentation method it deems suitable.
It is desirable to keep the set of possible disposition types small
and well defined, to avoid needless complexity. Even so, evolving