* src/procmime.h
[claws.git] / 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