Communicating Presentation Information in Internet Messages: The Content-Disposition Header
RFC 1806

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 01

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.