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
                                                             August 1997


               Communicating Presentation Information in
                           Internet Messages:
                  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.

Abstract

   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.








 
RFC 2183                  Content-Disposition                August 1997


1.  Introduction

   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