Excerpts from mail: 8-Mar-93 Re: file attachments in MIME Don
Loflin(_at_)emx(_dot_)cc(_dot_)utexas (1734)
How about:
3. A new subtype of message (e.g. message/attachment). The default
disposition remains 'inline', and attachments are encapsulated in
the above subtype.
Does this violate the intentions of the 'message' type? I think it fits
the semantics quite well -- "enclosed (encapsulated) with this letter
are two attachments". Loose (inline) enclosures in a paper letter are
meant to be viewed when the main message is read; attachments not meant
to be viewed immediately would be in an envelope inside the letter.
Actually this would work pretty well -- as would the separate
Content-Disposition header. This also has the same advantage
Content-disposition has in terms of not modifying the base MIME
document, since it's a simple subtype addition. It has another
desirable property too, which is that existing implementatons will
probably treat it as a synonym for message/rfc822 and do something
reasonable with it. All in all, I don't see any strong reason to prefer
either solution over the other, except perhaps that Rens is already
working on a Content-Disposition RFC. Oh, yes, also Rens' approach
provides a neat way to get rid of the newly-added "FILENAME" parameter
in the base document, which is appealing.
A big advantage I see to this scheme is that all it takes
is registration of a new subtype, which doesn't require an RFC. Wouldn't
adding a new content-type parameter or a new header line require a new RFC?
Actually, you need at least a short RFC to register a new subtype, too,
so they come out even on this score as well.
This now strikes me as a problem with several solutions that are
acceptable to me. We should try to reach closure by mail, but if not I
think we should just settle it once and for all at the Columbus IETF
meeting. -- Nathaniel