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.
The MUA might instead
present the user of a bitmap terminal with an iconic
Perhaps it is not needed to be specific in this text about these
human factors aspects of UA implementation?
That is my feeling.
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.
Ok.
+ 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.
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:
I don't mind including a paragraph or two on that.
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.
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.
--
Steve Dorner, Qualcomm Incorporated. "Oog make mission statement."