[Top] [All Lists]

Content-Disposition Header

1993-06-22 05:12:23

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.


Network Working Group                                     J. Laurens Troost
Internet Draft: Content-Disposition                        

                              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-


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' 

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

<Prev in Thread] Current Thread [Next in Thread>