Excerpts from mail: 8-Mar-93 Re: file attachments in MIME Rens
Troost(_at_)lorax(_dot_)shears (1368)
I lean toward the separate header, since it keeps disposition info
separate from type info, which to me is an important conceptual
separation. It would be nice to put the filename as a parameter to the
content-disposition as well; it belongs there, as being
non-type-related, and might address the clash with
message/external-body NAME semantics which Crispin pointed out.
This will probably not be feasible, though, given that 1341 is so far
along.
Well, now, this is interesting. Bear in mind that the filename
parameter was not in RFC 1341 in the first place, but was added for the
revised spec. This suggests that we could REDUCE the number of changes
from RFC 1341 *and* be more consistent with your model by simply
eliminating the filename parameter from the revised MIME spec, in favor
of allowing a Content-Disposition header to include a suggested file
name, e.g.
Content-disposition: attachment; filename=/vmunix
I think this would be a fine idea. It would also allow us to roll back
to the way the "Name" parameter was used in RFC 1341, which would
probably make several implementors (myself included) very happy.
Does anyone object to the idea of rolling back the changes related to
"filename" in favor of putting them into the new RFC describing
Content-disposition, which Rens is drafting? (Please note that I'm not
asking anyone to endorse Rens' document in advance, merely the concept
of shunting "filename" off to that new header and new RFC.) If we can
agree on this, then the new MIME spec will have even fewer changes from
RFC 1341, and we might be able to submit it as a Draft Standard
immediately after the Columbus IETF meeting. Sound good? -- Nathaniel