Re: MIME's "Content-Disposition" Header
Olle Jarnefors <ojarnef@admin.kth.se> Tue, 17 January 1995 23:50 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13337; 17 Jan 95 18:50 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13333; 17 Jan 95 18:50 EST
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa16775; 17 Jan 95 18:50 EST
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA20364; Tue, 17 Jan 95 18:42:06 EST
Received: from othello.admin.kth.se by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA20360; Tue, 17 Jan 95 18:42:03 EST
Received: from mercutio.admin.kth.se by othello.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0b) id AA04370; Wed, 18 Jan 95 00:41:57 +0100
Received: by mercutio.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0) id AA09597; Wed, 18 Jan 95 00:41:54 +0100
Date: Wed, 18 Jan 1995 00:41:54 +0100
Message-Id: <9501172341.AA09597@mercutio.admin.kth.se>
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Olle Jarnefors <ojarnef@admin.kth.se>
To: ietf-822@dimacs.rutgers.edu
Cc: Olle Jarnefors <ojarnef@admin.kth.se>
In-Reply-To: <199501132117.QAA17022@wilma.cs.utk.edu> (Wed, 11 Jan 1995 15:57:41 -0500; From: Rens Troost <rens@imsi.com>)
References: <199501132117.QAA17022@wilma.cs.utk.edu> <199501132117.QAA17022@wilma.cs.utk.edu> (Fri, 13 Jan 1995 16:17:27 -0500; From: Keith Moore <moore@cs.utk.edu>)
Subject: Re: MIME's "Content-Disposition" Header
I have the following comments on the substance of the Content-Disposition Internet Draft. > Internet Draft: draft-dorner-content-header-00.txt > Rens Troost > Steve Dorner > August 1994 > > Communicating Presentation Information in > Internet Messages: > The Content-Disposition Header > 3. The Content-Disposition Header Field > > Content-Disposition is an optional header; In its absence, > presentation should default to `inline'. > > 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. Disposition types defined in the future may be orthogonal to the already defined types, although mutually exclusive among themselves. Therefore I think we should explicitly allow multiple Content-Disposition: headers. If their disposition types are incompatible, it may be prescribed that the first one applies. This would make it unnecessary to further increase the complexity of the syntax of the Content-Dispostion: header. > 3.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. Of the two implementations outlined here the one for the more primitive equipment, character terminal, sounds the more useful to me! Instead of a bunch of icons on the bitmap terminal -- probably with only the word GIF in them, in the best case with a dot pattern perhaps hinting on the main features of the image -- I can on the character terminal expect a list of the attachments offered for viewing, probably showing the first line of the Content-Description header, possibly also the suggested filename and the approximate file size. In the character terminal case I can thus expect to get more information on which to base a decision to view or save an attachment or leave it. Perhaps it is not needed to be specific in this text about these human factors aspects of UA implementation? > 3.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. I suggest we here include words to the effect that the filename specified must not be regarded as containing an initial part specifying an absolute or relative path through a hierarchical file system. If this is required, the following security concerns may be dropped: > o+ Creating or overwriting system files (e.g., > "/etc/passwd"). > o+ Placing executable files into any command search path > (e.g., "~/bin/more"). > > o+ Sending the file to a pipe (e.g., "| sh"). By the way, are backspaces (^H), as used in the Security Considerations section, really allowed in the plain text form of Internet Drafts and RFCs? Back to section 3.3. > If the > receiving MUA writes the entity to a file, the suggested > filename should be used where possible. Considering what's said later about the dangers of certain filenames and the role of the reciever in choosing filename, this should be reworded to something like: + If the receiving MUA writes the entity to a file, the + filename specified in the Filename parameter can be + offered to the user as a suggested filename. > It is important that the receiving MUA not simply blindly use > the suggested filename. The suggested filename should be > checked (and possibly changed) to see that it conforms to > local filesystem conventions and that it does not present a ^ ! Add here: ", that it is not already used by an existing file" > security problem (see Security Considerations below). In my opinion it would also be useful to include at this point in the draft some advice for the _sending_ UA regarding the portability of filenames. Something along these lines: + In email communication it is often the case that the + sender have little or no knowledge about the + capabilities of the receiver's system or even which + operating system the receiver uses. In many cases the + sender should therefore choose a _portable_ filename. + The UA can help the user by pointing out portability risks + in a chosen filename. + + Two levels of filename portability are relevant in + an international context: + + 1) "Conservative" portability requirements: The filename + consists of 1-8 characters, possibly followed by "." + and 1-3 characters. The first character of both of the + filename parts is a letter. The characters are chosen + from this subset of US-ASCII: + + ABCDEFGHIJKLMNOPQRSTUVWXYZ + 0123456789 + + Filenames satisfying these requirements can in general be + used without problems in the operating systems MS-DOS, + Apple Macintosh, Unix, VMS, VM, MVS, OS/2, Microsoft + Windows NT. Warning: In the MS-DOS operating system a few + initial filename parts are unusable, since they are + reserved for devices. Among them are AUX, COM1, COM2, + COM3, COM4, CON, LPT1, LPT2, LPT3, NUL, PRN. + + 2) "Optimistic" portability requirements: The filename + consists of 1-31 characters. The characters are chosen + from this subset of US-ASCII: + + ABCDEFGHIJKLMNOPQRSTUVWXYZ + abcdefghijklmnopqrstuvwxyz + 0123456789 + !#$%&+-.=@[]^_`{}~ + + The filenames are regarded as case-insensitive, though, + if filenames are provided for several different body parts. + + Of the US-ASCII characters, control characters, SP and + these are excluded: + + "'()*,/:;<>?\| + + Filenames satisfying these requirements can in general be + used without problems in modern operating systems allowing + "long" filenames, such as Apple Macintosh, modern variants + of Unix, OS/2, Microsoft Windows NT. Considering that the conservative approach # 1 makes "self-explaining" filenames impossible in most cases (mostly because of the length restriction) I propose that a new parameter, Portable-Filename, is introduced. Its values would have a restricted syntax. It could be used together with the Filename parameter like in this example: Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=Futhark-A-fonttable-300.gif; portable-filename=FUTHARKA.GIF Content-Description: A table showing all glyphs of the main runic font Futhark A, in 300 dpi resolution. > The value of the filename parameter must be in US-ASCII. > However, it is possible to use arbitrary characters in the > filename by using the "quoted- phrase" construct and > [RFC 1522] encoding. There is an ambiguity between > quoted-string and quoted-phrase. It should be resolved in > favor of the quoted-phrase when possible; a filename fitting > the syntax of a series of encoded-words and atoms should be > treated as such. I would prefer a new encoding method, something similar to what Keith Moore has proposed recently, in <199501132117.QAA17022@wilma.cs.utk.edu>. It's important that the charset of the filename itself can be indicated, but in view of possible future parameters with purely binary values the charset indication should be optional. I suppose this isn't possible if an unmodified RFC 1522 encoding is used, spurious charset values will have to be used. > 3.4 Future Extensions and Unrecognized Disposition Types > > In the likely event that new parameters or types are needed, > they should be registered with the IANA, in the manner > specified in [RFC 1521], appendix E. An adapted version of registration form E.2 should be included in this draft. An important aspect of saving a body part to a file, that is not covered by the present draft, is which sections of the body part should be saved: the body of the body part, the headers of the body part, or both. It might also be appropriate to save both sections, but in different files. One approach to this problem is to indicate a "reasonable behaviour" for the different content-types defined in draft-ietf-822ext-mime-imb-01.txt. I think this can be said: Text/Plain: Save body. Reverse transport-encoding and convert to the local character set (if needed and possible). Image/GIF: Save body. Reverse transport-encoding. Choose a filename ending in ".gif". Image/JPEG: Save body. Reverse transport-encoding. Choose a filename ending in ".jpeg". Audio/Basic: Save body. Reverse transport-encoding. Choose a filename ending in ".au" (or whatever is dominant in current practice). Video/MPEG: Save body. Reverse transport-encoding. Choose a filename ending in ".mpeg". Application/Octet-Stream: Save body. Reverse transport-encoding. Application/PostScript: Save body. Reverse transport-encoding. Choose a filename ending in ".ps". Multipart/Mixed and Multipart/Digest: Ask the user if the body parts should be saved in individual files. If not: Save both headers and body. Choose a filename ending in ".msg". Multipart/Alternative: Find out if the user want's only the best alternative to be saved. If not: Save both headers and body. Choose a filename ending in ".msg". Multipart/Parallel: ? Wasn't this content-type to be scrapped? What is otherwise the semantics of Content-Disposition: attachment with this content-type? Message/RFC822: Save body (which, however, itself consists of both headers and body). Choose a filename ending in ".msg". Message/Partial: Try to find all the message fragments and reassemble them. Save the reassembled headers and body. Choose a filename ending in ".msg". Message/External-Body: Find out if the user wants the body data to be fetched now or later. In the first case, do that and save the reconstructed body (which, however, itself consists of both headers and body). Choose a filename ending in ".msg". I have here proposed the filename extension ".msg" in all cases where the resulting file has the format of an RFC 822 message. If the headers and the body are saved in two separate files, I would recommend that the name of the headers file is formed by adding ".M" (for "meta information") to the name of the body file. (This presupposes a file system that allows long filenames.) These pragmatic guidelines should not always be followed, of course. For example, the headers of a Image/GIF body part may contain useful information that is not captured by the filename, such as a Content-Description: or a Content-ID: header. A Text/Plain body part may include useful Content-Language: information. The sender may be able to specify the best behavior. I would therefore like to propose yet another new parameter, File-Coverage, taking one of the values: entity, headers, body. It should apply to the nearest preceding Filename parameter and Portable-Filename parameter. This means that filenames for both a headers file and a body file can be specified by multiple Filename and Portable-Filename parameters. The order of the parameters in a Content-Disposition: header will then be significant. -- Olle Jarnefors, Royal Institute of Technology, Stockholm <ojarnef@admin.kth.se>
- Re: A bad journey (an apocryphal war story) Alain FONTAINE (Postmaster - UCL)
- Re: A bad journey (an apocryphal war story) Keith Moore
- Re: Newline problem: Another stab Alain FONTAINE (Postmaster - UCL)
- Re: restrictions when defining charsets Keld J|rn Simonsen
- Comment on the draft MIME Part 1 document Olle Jarnefors
- Re: Comment on the draft MIME Part 1 document Nathaniel Borenstein
- Re: Comment on the draft MIME Part 1 document Olle Jarnefors
- Re: Comment on the draft MIME Part 1 document Nathaniel Borenstein
- Re: Comment on the draft MIME Part 1 document Dana S Emery
- Re: Comment on the draft MIME Part 1 document John C Klensin
- Re: Comment on the draft MIME Part 1 document John C Klensin
- Re: Comment on the draft MIME Part 1 document Nathaniel Borenstein
- Re: Comment on the draft MIME Part 1 document John C Klensin
- Re: Comment on the draft MIME Part 1 document John C Klensin
- Re: Comment on the draft MIME Part 1 document Dana S Emery
- Re: Comment on the draft MIME Part 1 document Nathaniel Borenstein
- Re: Comment on the draft MIME Part 1 document Keith Moore
- Re: Comment on the draft MIME Part 1 document t.l.hansen
- Re: Comment on the draft MIME Part 1 document Keith Moore
- Re: Comment on the draft MIME Part 1 document t.l.hansen
- Re: Comment on the draft MIME Part 1 document Keith Moore
- Re: Comment on the draft MIME Part 1 document John C Klensin
- Re: Comment on the draft MIME Part 1 document Olle Jarnefors
- Re: Comment on the draft MIME Part 1 document Olle Jarnefors
- Re: Comment on the draft MIME Part 1 document Keith Moore
- Re: Comment on the draft MIME Part 1 document Harald Tveit Alvestrand
- Re: Comment on the draft MIME Part 1 document John C Klensin
- Re: Comment on the draft MIME Part 1 document Keith Moore
- RE: Comment on the draft MIME Part 1 document Ned Freed
- Re: Comment on the draft MIME Part 1 document Alain FONTAINE (Post master - UCL)
- Re: Comment on the draft MIME Part 1 document Nathaniel Borenstein
- Non-ASCII Internet addresses? (Was: Comment on th… Olle Jarnefors
- Non-ASCII Internet addresses? (Was: Comment on th… Olle Jarnefors
- re: Non-ASCII Internet addresses? (Was: Comment o… t.l.hansen
- re: Non-ASCII Internet addresses? (Was: Comment o… David Herron
- re: Non-ASCII Internet addresses? (Was: Comment o… t.l.hansen
- Re: Non-ASCII Internet addresses? (Was: Comment o… Keith Moore
- Re: Non-ASCII Internet addresses? (Was: Comment o… Keith Moore
- Re: Non-ASCII Internet addresses? (Was: Comment o… Masataka Ohta
- Re: Non-ASCII Internet addresses? (Was: Comment o… Masataka Ohta
- Re: Non-ASCII Internet addresses? Olle Jarnefors
- Re: Non-ASCII Internet addresses? Olle Jarnefors
- Re: MIME for VM/CMS Rick Troth
- Re: MIME for VM/CMS Rick Troth
- Re: MIME for VM/CMS John C Klensin
- Re: Massive Content-Type definition ideas & Gopher Nathaniel Borenstein
- Re: MTAs and Content-Transfer-Encoding conversions Keld J|rn Simonsen
- Re: MTAs and Content-Transfer-Encoding conversions Nathaniel Borenstein
- Re: Ambiguity on 8859-* and bi-directionality Keld J|rn Simonsen
- Re: Ambiguity on 8859-* and bi-directionality Masataka Ohta
- Re: Ambiguity on 8859-* and bi-directionality Masataka Ohta
- Re: Ambiguity on 8859-* and bi-directionality Keld J|rn Simonsen
- Re: Ambiguity on 8859-* and bi-directionality Masataka Ohta
- Re: Ambiguity on 8859-* and bi-directionality Keith Moore
- Re: interoperablity Keld J|rn Simonsen
- Re: 8-bit transmission in NNTP Keld J|rn Simonsen
- Re: 8-bit transmission in NNTP Keith Moore
- Re: 8-bit transmission in NNTP Mark.R.Horton
- Re: 8-bit transmission in NNTP Paul Rarey
- Re: 8-bit transmission in NNTP Masataka Ohta
- Re: 8-bit transmission in NNTP Rick Troth
- Re: 8-bit transmission in NNTP Keith Moore
- Re: 8-bit transmission in NNTP Ned Freed
- Re: 8-bit transmission in NNTP Masataka Ohta
- Re: 8-bit transmission in NNTP Rick Troth
- Re: New to the list... Keld J|rn Simonsen
- Re: interoperablity Keld J|rn Simonsen
- Re: interoperablity Keith Moore
- Re: interoperablity Keith Moore
- Re: interoperablity Keld J|rn Simonsen
- Re: interoperablity Keld J|rn Simonsen
- Re: MIME's "Content-Disposition" Header Olle Jarnefors
- Re: MIME's "Content-Disposition" Header Ned Freed
- Re: MIME's "Content-Disposition" Header Harald.T.Alvestrand
- Re: MIME's "Content-Disposition" Header Olle Jarnefors
- Re: MIME's "Content-Disposition" Header Olle Jarnefors
- Re: Content-Disposition changes Olle Jarnefors
- Andre' PIRARD