RFC 2183 Proposed Standard Message format

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

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"). [STANDARDS-TRACK]

Status
Proposed Standard. On the standards track and stable enough to implement against. Most of the email stack stays at this level permanently.
Published
August 1997
Authors
R. Troost, S. Dorner, K. Moore
Read it
rfc-editor.org · errata · DOI

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

Normative requirements

Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 5 must, 4 should, 3 may.

2 The Content-Disposition Header Field

  • MUSTquoted-date-time := quoted-string ; contents MUST be an RFC 822 `date-time' ; numeric timezones (+HHMM or -HHMM) MUST be used
  • SHOULDNOTE ON PARAMETER VALUE LENGHTS: A short (length <= 78 characters) parameter value containing only non-`tspecials' characters SHOULD be represented as a single `token'.
  • SHOULDA short parameter value containing only ASCII characters, but including `tspecials' characters, SHOULD be represented as `quoted-string'.
  • MUSTParameter values longer than 78 characters, or which contain non-ASCII characters, MUST be encoded as specified in [RFC 2184].

2.3 The Filename Parameter

  • SHOULDThe suggested filename SHOULD be checked (and possibly changed) to see that it conforms to local filesystem conventions, does not overwrite an existing file, and does not present a security problem (see Security Considerations below).
  • SHOULD NOTThe receiving MUA SHOULD NOT respect any directory path information that may seem to be present in the filename parameter.

2.4 The Creation-Date parameter

  • MAYThe creation-date parameter MAY be used to indicate the date at which the file was created.
  • MUSTIf this parameter is included, the paramter value MUST be a quoted-string which contains a representation of the creation date of the file in [RFC 822] `date-time' format.

2.5 The Modification-Date parameter

  • MAYThe modification-date parameter MAY be used to indicate the date at which the file was last modified.
  • MUSTIf the modification-date parameter is included, the paramter value MUST be a quoted-string which contains a representation of the last modification date of the file in [RFC 822] `date-time' format.

2.6 The Read-Date parameter

  • MAYThe read-date parameter MAY be used to indicate the date at which the file was last read.
  • MUSTIf the read-date parameter is included, the parameter value MUST be a quoted-string which contains a representation of the last-read date of the file in [RFC 822] `date- time' format.

Every current email RFC