"Fossies" - the Fresh Open Source Software Archive

Member "libgcgi.a-0.9.5/doc/rfc1806.txt" (22 Jun 2002, 15548 Bytes) of package /linux/www/old/gcgi-0.9.5.tar.gz:


As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    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 
   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 
  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 
  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 
  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 
  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 
  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 
  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