ietf-822
[Top] [All Lists]

Re: file attachments in MIME

1993-03-08 08:25:49
I don't think we're as far from closure on this subject as the volume of
traffic might suggest.  Let me have a stab at moving us towards closing
up this issue:

I don't think anyone denies that we need to do something to
differentiate the inline and attachment models of compound messages.  As
I see it there are two main proposals on the floor:

1.  A new multipart subtype (e.g. multipart/attachment)

2.  A new body part attribute.  This has been suggested  as a
Content-Disposition header, but I think it could easily and gracefully
be handled as a content-type parameter (disposition=attachment or
disposition=inline).  At any rate, the choice here is basically
syntactic and not critical.

The most important thing we have to do is to choose between these two
models.  I would argue that approach #1 is fundamentally flawed. 
Sometimes you will have something that has N parts, most of which are
in-line, and a couple of which are attachments.  In model #1, you'll
need to do this with some rather convoluted multipart nesting, whereas
it will be quite natural with model #2.

Does anyone object strongly to model #2?  If not, then all we need to do
is choose a syntax (I'd vote for a content-type parameter) and a default
(I'd argue that the default disposition be "inline", because I believe
that model was implicit in RFC 1341.  If you don't believe that,  look
at the multipart examples in RFC 1341, many of which simply don't make
as much sense with an "attachment" semantics.

Here's hoping I'm right and the remaining decisions are relatively
small...  -- Nathaniel

<Prev in Thread] Current Thread [Next in Thread>