Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field
obsoletes
- rfc-1806 — Communicating Presentation Information in Internet Messages: The Content-Disposition Header
updated by
Extracted elements (23)
No provision is made for specifying directory path information in the filename parameter; portable specification of directory paths is deferred to a possible future Content-Disposition parameter. The current parameter is intentionally terminal-component-only.
The filename parameter is permitted on 'inline' body parts as well as 'attachment' parts. These parts will not normally be written to files, but the parameter provides a filename if the receiving user chooses to save the part.
The set of possible disposition types is intentionally kept small and well defined to avoid needless complexity, while the set is made extensible via IANA registration to accommodate evolving usage.
Unrecognized disposition types are treated as 'attachment' rather than 'inline' because a sender who goes to the trouble of producing a Content-Disposition header with a novel type is more likely aiming for something more elaborate than inline presentation.
Content-Disposition is an optional header; in its absence, the MUA may use whatever presentation method it deems suitable. MIME content-type parameters are per-content-type, whereas Content-Disposition parameters are valid for all dispositions.
If a Content-Disposition header is used on a multipart body part, it applies to the multipart as a whole, not the individual subparts. Subpart dispositions should not be consulted until the multipart itself is presented.
It is permissible to use Content-Disposition on the main body of an RFC 822 message, not only on MIME body parts.
Contents of quoted-date-time fields MUST be an RFC 822 date-time, and numeric timezones (+HHMM or -HHMM) MUST be used rather than named timezone abbreviations.
New Content-Disposition values beyond 'inline' and 'attachment' may be defined only by Internet standards-track documents, or in Experimental documents approved by the IESG.
Parameter values longer than 78 characters, or which contain non-ASCII characters, MUST be encoded as specified in RFC 2184. Short values with only non-tspecials characters SHOULD be a single token; short ASCII values with tspecials SHOULD be quoted-string.
The receiving MUA SHOULD check (and possibly change) the suggested filename to ensure it conforms to local filesystem conventions, does not overwrite an existing file, and does not present a security problem.
The receiving MUA SHOULD NOT respect any directory path information that may appear in the filename parameter. The filename should be treated as a terminal component only.
Unrecognized Content-Disposition parameters SHOULD be ignored. Unrecognized disposition types SHOULD be treated as 'attachment'.
The 'attachment' disposition type designates a body part as separate from the main mail body; its display should not be automatic but contingent upon further user action. MUAs may present attachments as icons or a selectable list.
The 'creation-date' parameter MAY indicate the date at which the file was created. Its value MUST be a quoted-string containing an RFC 822 date-time. UNIX implementors are cautioned that st_ctime is not the creation time and is inappropriate as a source value.
The 'filename' parameter suggests a filename to use if the entity is detached and stored in a separate file. It is valid for any disposition type, including 'inline', and its presence does not force an implementation to write the entity to a file.
The 'inline' disposition type indicates a body part is intended to be displayed automatically upon display of the message. Inline body parts should be presented in the order in which they occur, subject to normal multipart semantics.
The 'modification-date' parameter MAY indicate the date at which the file was last modified. Its value MUST be a quoted-string containing an RFC 822 date-time representation of the last modification date.
The 'read-date' parameter MAY indicate the date at which the file was last read. Its value MUST be a quoted-string containing an RFC 822 date-time representation of the last-read date.
The 'size' parameter indicates an approximate size of the file in octets (encoded as 1*DIGIT). It can be used to pre-allocate space before storing or to check whether sufficient space exists.
New Content-Disposition disposition-type values (beyond 'inline' and 'attachment') require standards-track or IESG-approved Experimental RFC publication. New parameters may be registered with IANA by submitting a template specifying parameter name, allowable values, and description to IANA@IANA.ORG.
A receiving MUA must take care that the sender's suggested filename does not represent a hazard, including creating startup or system files, overwriting existing files, placing executables in command search paths, or sending files to a pipe. The MUA should not name or place the file such that it will be interpreted or executed without explicit user action.
Content-Disposition header field is defined in RFC 822 extended BNF as: disposition-type ('inline' | 'attachment' | extension-token) followed by zero or more semicolon-separated disposition-parm values (filename-parm, creation-date-parm, modification-date-parm, read-date-parm, size-parm, or generic parameter). Disposition-type values are not case-sensitive.