summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1806.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1806.txt')
-rw-r--r--doc/rfc/rfc1806.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc1806.txt b/doc/rfc/rfc1806.txt
new file mode 100644
index 0000000..2b48317
--- /dev/null
+++ b/doc/rfc/rfc1806.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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.
+
+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 Filename Parameter
+
+ The sender may want to suggest a filename to be used if the entity is
+ detached and stored in a separate file. If the receiving MUA writes
+ the entity to a file, the suggested filename should be used as a
+ basis for the actual filename, where possible.
+
+ It is important that the receiving MUA not blindly use the suggested
+ filename. The 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).
+
+ The receiving MUA should not respect any directory path information
+ that may seem to be present in the filename parameter. The filename
+ should be treated as a terminal component only. Portable
+ specification of directory paths might possibly be done in the future
+ via a separate Content-Disposition parameter, but no provision is
+ made for it in this draft.
+
+ Current [RFC 1521] grammar restricts parameter values (and hence
+ Content-Disposition filenames) to US-ASCII. We recognize the great
+ desirability of allowing arbitrary character sets in filenames, but
+ it is beyond the scope of this document to define the necessary
+ mechanisms. We expect that the basic [RFC 1521] `value'
+ specification will someday be amended to allow use of non-US-ASCII
+ characters, at which time the same mechanism should be used in the
+ Content-Disposition filename parameter.
+
+
+
+
+
+
+Troost & Dorner Experimental [Page 3]
+
+RFC 1806 Content-Disposition June 1995
+
+
+ Beyond the limitation to US-ASCII, the sending MUA may wish to bear
+ in mind the limitations of common filesystems. Many have severe
+ length and character set restrictions. Short alphanumeric filenames
+ are least likely to require modification by the receiving system.
+
+ The presence of the filename parameter does not force an
+ implementation to write the entity to a separate file. It is
+ perfectly acceptable for implementations to leave the entity as part
+ of the normal mail stream unless the user requests otherwise. As a
+ consequence, the parameter may be used on any MIME entity, even
+ `inline' ones. These will not normally be written to files, but the
+ parameter could be used to provide a filename if the receiving user
+ should choose to write the part to a file.
+
+2.4 Future Extensions and Unrecognized Disposition Types
+
+ In the likely event that new parameters or disposition types are
+ needed, they should be registered with the IANA, in the manner
+ specified in [RFC 1521], appendix E.
+
+ Once new disposition types and parameters are defined, there is of
+ course the likelihood that implementations will see disposition types
+ and parameters they do not understand. Furthermore, since x-tokens
+ are allowed, implementations may also see entirely unregistered
+ disposition types and parameters.
+
+ Unrecognized parameters should be ignored. Unrecognized disposition
+ types should be treated as `attachment'. The choice of `attachment'
+ for unrecognized types is made because a sender who goes to the
+ trouble of producing a Content-Disposition header with a new
+ disposition type is more likely aiming for something more elaborate
+ than inline presentation.
+
+ Unless noted otherwise in the definition of a parameter, Content-
+ Disposition parameters are valid for all dispositions. (In contrast
+ to [RFC 1521] content-type parameters, which are defined on a per-
+ content-type basis.) Thus, for example, the `filename' parameter
+ still means the name of the file to which the part should be written,
+ even if the disposition itself is unrecognized.
+
+2.5 Content-Disposition and Multipart
+
+ If a Content-Disposition header is used on a multipart body part, it
+ applies to the multipart as a whole, not the individual subparts.
+ The disposition types of the subparts do not need to be consulted
+ until the multipart itself is presented. When the multipart is
+ displayed, then the dispositions of the subparts should be respected.
+
+
+
+
+Troost & Dorner Experimental [Page 4]
+
+RFC 1806 Content-Disposition June 1995
+
+
+ If the `inline' disposition is used, the multipart should be
+ displayed as normal; however, an `attachment' subpart should require
+ action from the user to display.
+
+ If the `attachment' disposition is used, presentation of the
+ multipart should not proceed without explicit user action. Once the
+ user has chosen to display the multipart, the individual subpart
+ dispositions should be consulted to determine how to present the
+ subparts.
+
+2.6 Content-Disposition and the Main Message
+
+ It is permissible to use Content-Disposition on the main body of an
+ [RFC 822] message.
+
+3. Examples
+
+ Here is a an example of a body part containing a JPEG image that is
+ intended to be viewed by the user immediately:
+
+ Content-Type: image/jpeg
+ Content-Disposition: inline
+ Content-Description: just a small picture of me
+
+ <jpeg data>
+
+ The following body part contains a JPEG image that should be
+ displayed to the user only if the user requests it. If the JPEG is
+ written to a file, the file should be named "genome.jpg":
+
+ Content-Type: image/jpeg
+ Content-Disposition: attachment; filename=genome.jpeg
+ Content-Description: a complete map of the human genome
+
+ <jpeg data>
+
+ The following is an example of the use of the `attachment'
+ disposition with a multipart body part. The user should see text-
+ part-1 immediately, then take some action to view multipart-2. After
+ taking action to view multipart-2, the user will see text-part-2
+ right away, and be required to take action to view jpeg-1. Subparts
+ are indented for clarity; they would not be so indented in a real
+ message.
+
+ Content-Type: multipart/mixed; boundary=outer
+ Content-Description: multipart-1
+
+ --outer
+
+
+
+Troost & Dorner Experimental [Page 5]
+
+RFC 1806 Content-Disposition June 1995
+
+
+ Content-Type: text/plain
+ Content-Disposition: inline
+ Content-Description: text-part-1
+
+ Some text goes here
+
+ --outer
+ Content-Type: multipart/mixed; boundary=inner
+ Content-Disposition: attachment
+ Content-Description: multipart-2
+
+ --inner
+ Content-Type: text/plain
+ Content-Disposition: inline
+ Content-Description: text-part-2
+
+ Some more text here.
+
+ --inner
+ Content-Type: image/jpeg
+ Content-Disposition: attachment
+ Content-Description: jpeg-1
+
+ <jpeg data>
+ --inner--
+ --outer--
+
+4. Summary
+
+ Content-Disposition takes one of two values, `inline' and
+ `attachment'. 'Inline' indicates that the entity should be
+ immediately displayed to the user, whereas `attachment' means that
+ the user should take additional action to view the entity.
+
+ The `filename' parameter can be used to suggest a filename for
+ storing the bodypart, if the user wishes to store it in an external
+ file.
+
+5. Security Considerations
+
+ There are security issues involved any time users exchange data.
+ While these are not to be minimized, neither does this memo change
+ the status quo in that regard, except in one instance.
+
+ Since this memo provides a way for the sender to suggest a filename,
+ a receiving MUA must take care that the sender's suggested filename
+ does not represent a hazard. Using UNIX as an example, some hazards
+ would be:
+
+
+
+Troost & Dorner Experimental [Page 6]
+
+RFC 1806 Content-Disposition June 1995
+
+
+ + Creating startup files (e.g., ".login").
+
+ + Creating or overwriting system files (e.g.,
+ "/etc/passwd").
+
+ + Overwriting any existing file.
+
+ + Placing executable files into any command search path
+ (e.g., "~/bin/more").
+
+ + Sending the file to a pipe (e.g., "| sh").
+
+ In general, the receiving MUA should never name or place the file
+ such that it will get interpreted or executed without the user
+ explicitly initiating the action.
+
+ It is very important to note that this is not an exhaustive list; it
+ is intended as a small set of examples only. Implementors must be
+ alert to the potential hazards on their target systems.
+
+6. References
+
+ [RFC 1521]
+ Borenstein N., and N. Freed, "MIME (Multipurpose Internet
+ Mail Extensions) Part One: Mechanisms for Specifying and
+ Describing the Format of Internet Message Bodies",
+ RFC 1521, Bellcore, Innosoft, September 1993.
+
+ [RFC 822]
+ Crocker, D., "Standard for the Format of ARPA Internet
+ Text Messages", STD 11, RFC 822, UDEL, August 1982.
+
+7. Acknowledgements
+
+We gratefully acknowledge the help these people provided
+during the preparation of this draft:
+
+ Nathaniel Borenstein
+ Ned Freed
+ Keith Moore
+ Dave Crocker
+ Dan Pritchett
+
+
+
+
+
+
+
+
+
+Troost & Dorner Experimental [Page 7]
+
+RFC 1806 Content-Disposition June 1995
+
+
+8. Authors' Addresses
+
+ Rens Troost
+ New Century Systems
+ 324 East 41st Street #804
+ New York, NY, 10017 USA
+
+ Phone: +1 (212) 557-2050
+ Fax: +1 (212) 557-2049
+ EMail: rens@century.com
+
+
+ Steve Dorner
+ QUALCOMM Incorporated
+ 6455 Lusk Boulevard
+ San Diego, CA 92121
+ USA
+
+ EMail: sdorner@qualcomm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Troost & Dorner Experimental [Page 8]
+