Re: MIME's "Content-Disposition" Header

[Ned Freed <[e-mail]>]

> I'm a little confused as to why this issue isn't considered more
> critical within the MIME community.  Successfully transmitting the name
> of an attachment and correctly noting whether some textual information
> is to be treated as an attachment or as part of the message body is
> also very important.  We have some pretty bad failure modes when this
> information is not correctly transmitted.

I agree that the content-disposition proposal should advance at this time.
However, I don't think your reasons for doing this are particularly relevant.
File name information can be useful, but it should not be essential. Something
is very wrong if it is essential.

> In particular:

> like several other PC-based mail clients, we use a specially-named
> attachment to pass custom rich text, custom attributes and forms
> information.  When this name isn't preserved, the MIME-based Unix
> version can't recognize this information.  (Note that we're trying to
> get this through gateways, so we're not simply talking MIME to MIME
> mailer here and that limits the strategies we can take).

Sounds to me like you need to define a new content-type or types for this. The
gateway can then turn the content-type label into whatever is appropriate on
the other side, and vice versa.

File names are not an appropriate vehicle for carrying type information. They
vary too much, and security considerations sometimes mandate the removal of
file name information.

> Also, by default the client will send the text body as both plain text
> and within this special attachment (along with the formatting info).
> When our client receives the message, it assumes the text of the
> message is completely specified in the attachment and discards the
> actual body.  If a gateway has inserted the attachment into the body,
> the attachment is completely lost (I won't go into details about why
> this makes sense).  Bottom line is the Content-Disposition becomes a
> pretty important piece of information.

Sufficiently important that you should be using an existing, well defined
mechanism, I'd say.

				Ned