Steve Dorner writes:
At 5:41 PM 1/17/95, Olle Jarnefors wrote:
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.
I'm not willing to complicate the header in that way. More complex
behaviors can be made by defining new dispositions and using parameters to
indicate sub-behaviors like inline and attachment. I want to keep it
simple.
Maybe it's better to define new Content-* headers, as Harald
Alvestrand has suggested. At some suitable point in the draft,
section 3 or 3.4 probably, should then be inserted text to the
effect that all disposition types are intended to be mutually
exclusive.
+ 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.
I don't want the RFC to require user intervention.
Neither do I. Would the verb "may" be better than "can"?
The filename parameter is for the body of the message to be saved. If you
want to define an extra parameter in another draft that specifies where the
header should be saved, I think that would be fine.
The best way to draw the line would be between the "inline" and
"attachment" disposition types on one hand, and the "filename"
parameter and possibly other parameters related to saving body
parts on the other hand, it seems to me.
I don't think we can say in general that the information in the
headers of a body part is always useless, nor that it's of no
interest whether only the body of a body part is saved, or the
whole body part, including headers.
To compare with a similar application: I think it is a pity that
data describing the original Internet site, the path, the
original filename, and the original modification time of a file
I copy to my own system by anonymous FTP is not automatically
recorded, e.g. in a metadata file with the extra file extension ".M".
--
Olle Jarnefors, Royal Institute of Technology, Stockholm
<ojarnef(_at_)admin(_dot_)kth(_dot_)se>