doc/src/rfc1806.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                          R. Troost
   8 Request for Comments: 1806                           New Century Systems
   9 Category: Experimental                                         S. Dorner
  10                                                    QUALCOMM Incorporated
  11                                                                June 1995
  12
  13
  14                Communicating Presentation Information in
  15                            Internet Messages:
  16                      The Content-Disposition Header
  17
  18 Status of this Memo
  19
  20    This memo defines an Experimental Protocol for the Internet
  21    community.  This memo does not specify an Internet standard of any
  22    kind.  Discussion and suggestions for improvement are requested.
  23    Distribution of this memo is unlimited.
  24
  25 Abstract
  26
  27    This memo provides a mechanism whereby messages conforming to the
  28    [RFC 1521] ("MIME") specification can convey presentational
  29    information.  It specifies a new "Content-Disposition" header,
  30    optional and valid for any [RFC 1521] entity ("message" or "body
  31    part"). Two values for this header are described in this memo; one
  32    for the ordinary linear presentation of the body part, and another to
  33    facilitate the use of mail to transfer files. It is expected that
  34    more values will be defined in the future, and procedures are defined
  35    for extending this set of values.
  36
  37    This document is intended as an extension to [RFC 1521]. As such, the
  38    reader is assumed to be familiar with [RFC 1521], and [RFC 822]. The
  39    information presented herein supplements but does not replace that
  40    found in those documents.
  41
  42 1.  Introduction
  43
  44    [RFC 1521] specifies a standard format for encapsulating multiple
  45    pieces of data into a single Internet message. That document does not
  46    address the issue of presentation styles; it provides a framework for
  47    the interchange of message content, but leaves presentation issues
  48    solely in the hands of mail user agent (MUA) implementors.
  49
  50    Two common ways of presenting multipart electronic messages are as a
  51    main document with a list of separate attachments, and as a single
  52    document with the various parts expanded (displayed) inline. The
  53    display of an attachment is generally construed to require positive
  54    action on the part of the recipient, while inline message components
  55
  56
  57
  58 Troost & Dorner               Experimental                      [Page 1]
  59 \f
  60 RFC 1806                  Content-Disposition                  June 1995
  61
  62
  63    are displayed automatically when the message is viewed. A mechanism
  64    is needed to allow the sender to transmit this sort of presentational
  65    information to the recipient; the Content-Disposition header provides
  66    this mechanism, allowing each component of a message to be tagged
  67    with an indication of its desired presentation semantics.
  68
  69    Tagging messages in this manner will often be sufficient for basic
  70    message formatting. However, in many cases a more powerful and
  71    flexible approach will be necessary. The definition of such
  72    approaches is beyond the scope of this memo; however, such approaches
  73    can benefit from additional Content-Disposition values and
  74    parameters, to be defined at a later date.
  75
  76    In addition to allowing the sender to specify the presentational
  77    disposition of a message component, it is desirable to allow her to
  78    indicate a default archival disposition; a filename. The optional
  79    "filename" parameter provides for this.
  80
  81 2.  The Content-Disposition Header Field
  82
  83    Content-Disposition is an optional header; in its absence, the MUA
  84    may use whatever presentation method it deems suitable.
  85
  86    It is desirable to keep the set of possible disposition types small
  87    and well defined, to avoid needless complexity. Even so, evolving
  88    usage will likely require the definition of additional disposition
  89    types or parameters, so the set of disposition values is extensible;
  90    see below.
  91
  92    In the extended BNF notation of [RFC 822], the Content-Disposition
  93    header field is defined as follows:
  94
  95         disposition := "Content-Disposition" ":"
  96                        disposition-type
  97                        *(";" disposition-parm)
  98
  99         disposition-type := "inline"
 100                           / "attachment"
 101                           / extension-token
 102                           ; values are not case-sensitive
 103
 104         disposition-parm := filename-parm / parameter
 105
 106         filename-parm := "filename" "=" value;
 107
 108    `Extension-token', `parameter' and `value' are defined according to
 109    [RFC 822] and [RFC 1521].
 110
 111
 112
 113
 114 Troost & Dorner               Experimental                      [Page 2]
 115 \f
 116 RFC 1806                  Content-Disposition                  June 1995
 117
 118
 119 2.1  The Inline Disposition Type
 120
 121    A bodypart should be marked `inline' if it is intended to be
 122    displayed automatically upon display of the message. Inline bodyparts
 123    should be presented in the order in which they occur, subject to the
 124    normal semantics of multipart messages.
 125
 126 2.2  The Attachment Disposition Type
 127
 128    Bodyparts can be designated `attachment' to indicate that they are
 129    separate from the main body of the mail message, and that their
 130    display should not be automatic, but contingent upon some further
 131    action of the user. The MUA might instead present the user of a
 132    bitmap terminal with an iconic representation of the attachments, or,
 133    on character terminals, with a list of attachments from which the
 134    user could select for viewing or storage.
 135
 136 2.3  The Filename Parameter
 137
 138    The sender may want to suggest a filename to be used if the entity is
 139    detached and stored in a separate file. If the receiving MUA writes
 140    the entity to a file, the suggested filename should be used as a
 141    basis for the actual filename, where possible.
 142
 143    It is important that the receiving MUA not blindly use the suggested
 144    filename.  The suggested filename should be checked (and possibly
 145    changed) to see that it conforms to local filesystem conventions,
 146    does not overwrite an existing file, and does not present a security
 147    problem (see Security Considerations below).
 148
 149    The receiving MUA should not respect any directory path information
 150    that may seem to be present in the filename parameter.  The filename
 151    should be treated as a terminal component only.  Portable
 152    specification of directory paths might possibly be done in the future
 153    via a separate Content-Disposition parameter, but no provision is
 154    made for it in this draft.
 155
 156    Current [RFC 1521] grammar restricts parameter values (and hence
 157    Content-Disposition filenames) to US-ASCII.  We recognize the great
 158    desirability of allowing arbitrary character sets in filenames, but
 159    it is beyond the scope of this document to define the necessary
 160    mechanisms.  We expect that the basic [RFC 1521] `value'
 161    specification will someday be amended to allow use of non-US-ASCII
 162    characters, at which time the same mechanism should be used in the
 163    Content-Disposition filename parameter.
 164
 165
 166
 167
 168
 169
 170 Troost & Dorner               Experimental                      [Page 3]
 171 \f
 172 RFC 1806                  Content-Disposition                  June 1995
 173
 174
 175    Beyond the limitation to US-ASCII, the sending MUA may wish to bear
 176    in mind the limitations of common filesystems.  Many have severe
 177    length and character set restrictions.  Short alphanumeric filenames
 178    are least likely to require modification by the receiving system.
 179
 180    The presence of the filename parameter does not force an
 181    implementation to write the entity to a separate file. It is
 182    perfectly acceptable for implementations to leave the entity as part
 183    of the normal mail stream unless the user requests otherwise. As a
 184    consequence, the parameter may be used on any MIME entity, even
 185    `inline' ones. These will not normally be written to files, but the
 186    parameter could be used to provide a filename if the receiving user
 187    should choose to write the part to a file.
 188
 189 2.4  Future Extensions and Unrecognized Disposition Types
 190
 191    In the likely event that new parameters or disposition types are
 192    needed, they should be registered with the IANA, in the manner
 193    specified in [RFC 1521], appendix E.
 194
 195    Once new disposition types and parameters are defined, there is of
 196    course the likelihood that implementations will see disposition types
 197    and parameters they do not understand.  Furthermore, since x-tokens
 198    are allowed, implementations may also see entirely unregistered
 199    disposition types and parameters.
 200
 201    Unrecognized parameters should be ignored. Unrecognized disposition
 202    types should be treated as `attachment'. The choice of `attachment'
 203    for unrecognized types is made because a sender who goes to the
 204    trouble of producing a Content-Disposition header with a new
 205    disposition type is more likely aiming for something more elaborate
 206    than inline presentation.
 207
 208    Unless noted otherwise in the definition of a parameter, Content-
 209    Disposition parameters are valid for all dispositions.  (In contrast
 210    to [RFC 1521] content-type parameters, which are defined on a per-
 211    content-type basis.) Thus, for example, the `filename' parameter
 212    still means the name of the file to which the part should be written,
 213    even if the disposition itself is unrecognized.
 214
 215 2.5  Content-Disposition and Multipart
 216
 217    If a Content-Disposition header is used on a multipart body part, it
 218    applies to the multipart as a whole, not the individual subparts.
 219    The disposition types of the subparts do not need to be consulted
 220    until the multipart itself is presented.  When the multipart is
 221    displayed, then the dispositions of the subparts should be respected.
 222
 223
 224
 225
 226 Troost & Dorner               Experimental                      [Page 4]
 227 \f
 228 RFC 1806                  Content-Disposition                  June 1995
 229
 230
 231    If the `inline' disposition is used, the multipart should be
 232    displayed as normal; however, an `attachment' subpart should require
 233    action from the user to display.
 234
 235    If the `attachment' disposition is used, presentation of the
 236    multipart should not proceed without explicit user action.  Once the
 237    user has chosen to display the multipart, the individual subpart
 238    dispositions should be consulted to determine how to present the
 239    subparts.
 240
 241 2.6  Content-Disposition and the Main Message
 242
 243    It is permissible to use Content-Disposition on the main body of an
 244    [RFC 822] message.
 245
 246 3.  Examples
 247
 248    Here is a an example of a body part containing a JPEG image that is
 249    intended to be viewed by the user immediately:
 250
 251          Content-Type: image/jpeg
 252          Content-Disposition: inline
 253          Content-Description: just a small picture of me
 254
 255          <jpeg data>
 256
 257    The following body part contains a JPEG image that should be
 258    displayed to the user only if the user requests it. If the JPEG is
 259    written to a file, the file should be named "genome.jpg":
 260
 261          Content-Type: image/jpeg
 262          Content-Disposition: attachment; filename=genome.jpeg
 263          Content-Description: a complete map of the human genome
 264
 265          <jpeg data>
 266
 267    The following is an example of the use of the `attachment'
 268    disposition with a multipart body part.  The user should see text-
 269    part-1 immediately, then take some action to view multipart-2.  After
 270    taking action to view multipart-2, the user will see text-part-2
 271    right away, and be required to take action to view jpeg-1.  Subparts
 272    are indented for clarity; they would not be so indented in a real
 273    message.
 274
 275          Content-Type: multipart/mixed; boundary=outer
 276          Content-Description: multipart-1
 277
 278          --outer
 279
 280
 281
 282 Troost & Dorner               Experimental                      [Page 5]
 283 \f
 284 RFC 1806                  Content-Disposition                  June 1995
 285
 286
 287            Content-Type: text/plain
 288            Content-Disposition: inline
 289            Content-Description: text-part-1
 290
 291            Some text goes here
 292
 293          --outer
 294            Content-Type: multipart/mixed; boundary=inner
 295            Content-Disposition: attachment
 296            Content-Description: multipart-2
 297
 298            --inner
 299              Content-Type: text/plain
 300              Content-Disposition: inline
 301              Content-Description: text-part-2
 302
 303              Some more text here.
 304
 305            --inner
 306              Content-Type: image/jpeg
 307              Content-Disposition: attachment
 308              Content-Description: jpeg-1
 309
 310              <jpeg data>
 311            --inner--
 312          --outer--
 313
 314 4.  Summary
 315
 316    Content-Disposition takes one of two values, `inline' and
 317    `attachment'.  'Inline' indicates that the entity should be
 318    immediately displayed to the user, whereas `attachment' means that
 319    the user should take additional action to view the entity.
 320
 321    The `filename' parameter can be used to suggest a filename for
 322    storing the bodypart, if the user wishes to store it in an external
 323    file.
 324
 325 5.  Security Considerations
 326
 327    There are security issues involved any time users exchange data.
 328    While these are not to be minimized, neither does this memo change
 329    the status quo in that regard, except in one instance.
 330
 331    Since this memo provides a way for the sender to suggest a filename,
 332    a receiving MUA must take care that the sender's suggested filename
 333    does not represent a hazard. Using UNIX as an example, some hazards
 334    would be:
 335
 336
 337
 338 Troost & Dorner               Experimental                      [Page 6]
 339 \f
 340 RFC 1806                  Content-Disposition                  June 1995
 341
 342
 343           + Creating startup files (e.g., ".login").
 344
 345           + Creating or overwriting system files (e.g.,
 346             "/etc/passwd").
 347
 348           + Overwriting any existing file.
 349
 350           + Placing executable files into any command search path
 351             (e.g., "~/bin/more").
 352
 353           + Sending the file to a pipe (e.g., "| sh").
 354
 355    In general, the receiving MUA should never name or place the file
 356    such that it will get interpreted or executed without the user
 357    explicitly initiating the action.
 358
 359    It is very important to note that this is not an exhaustive list; it
 360    is intended as a small set of examples only.  Implementors must be
 361    alert to the potential hazards on their target systems.
 362
 363 6.  References
 364
 365     [RFC 1521]
 366         Borenstein N., and N. Freed, "MIME (Multipurpose Internet
 367         Mail Extensions) Part One:  Mechanisms for Specifying and
 368         Describing the Format of Internet Message Bodies",
 369         RFC 1521, Bellcore, Innosoft, September 1993.
 370
 371     [RFC 822]
 372         Crocker, D., "Standard for the Format of ARPA Internet
 373         Text Messages", STD 11, RFC 822, UDEL, August 1982.
 374
 375 7.  Acknowledgements
 376
 377 We gratefully acknowledge the help these people provided
 378 during the preparation of this draft:
 379
 380             Nathaniel Borenstein
 381             Ned Freed
 382             Keith Moore
 383             Dave Crocker
 384             Dan Pritchett
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Troost & Dorner               Experimental                      [Page 7]
 395 \f
 396 RFC 1806                  Content-Disposition                  June 1995
 397
 398
 399 8.  Authors' Addresses
 400
 401    Rens Troost
 402    New Century Systems
 403    324 East 41st Street #804
 404    New York, NY, 10017 USA
 405
 406    Phone: +1 (212) 557-2050
 407    Fax: +1 (212) 557-2049
 408    EMail: rens@century.com
 409
 410
 411    Steve Dorner
 412    QUALCOMM Incorporated
 413    6455 Lusk Boulevard
 414    San Diego, CA 92121
 415    USA
 416
 417    EMail: sdorner@qualcomm.com
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450 Troost & Dorner               Experimental                      [Page 8]
 451 \f