Communicating Presentation Information in Internet Messages: The Content-Disposition Header
RFC 1806
Document | Type |
RFC - Experimental
(June 1995; No errata)
Obsoleted by RFC 2183
Was draft-dorner-content-header (individual)
|
|
---|---|---|---|
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 1806 (Experimental) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group R. Troost Request for Comments: 1806 New Century Systems Category: Experimental S. Dorner QUALCOMM Incorporated June 1995 Communicating Presentation Information in Internet Messages: The Content-Disposition Header Status of this Memo This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Abstract This memo provides a mechanism whereby messages conforming to the [RFC 1521] ("MIME") specification can convey presentational information. It specifies a new "Content-Disposition" header, optional and valid for any [RFC 1521] entity ("message" or "body part"). Two values for this header 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 [RFC 1521]. As such, the reader is assumed to be familiar with [RFC 1521], and [RFC 822]. The information presented herein supplements but does not replace that found in those documents. 1. Introduction [RFC 1521] 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 Troost & Dorner Experimental [Page 1] RFC 1806 Content-Disposition June 1995 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. 2. The Content-Disposition Header Field Content-Disposition is an optional header; 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 usage will likely require the definition of additional disposition types or parameters, so the set of disposition values is extensible; see below. In the extended BNF notation of [RFC 822], the Content-Disposition header field is defined as follows: disposition := "Content-Disposition" ":" disposition-type *(";" disposition-parm) disposition-type := "inline" / "attachment" / extension-token ; values are not case-sensitive disposition-parm := filename-parm / parameter filename-parm := "filename" "=" value; `Extension-token', `parameter' and `value' are defined according to [RFC 822] and [RFC 1521]. Troost & Dorner Experimental [Page 2] RFC 1806 Content-Disposition June 1995 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 presented in the order in which they occur, subject to the normal semantics of multipart messages.Show full document text