Actually, I'm more than a little sympathetic with this. My problem with
it is twofold: 1) What's broken in the MIME architecture that we need
to add a new header instead of using the set of facilities already
defined?
Nothing has to be broken in order to use a new header. New headers can be
used whenever we feel they are appropriate; this in no way implies that
something is broken because we make this choice.
2) If messages are saved to files, or cut and pasted back and forth, the
headers will tend to stick around, in which case the Content-Disposition will
tend to accidentally stick around.
I entirely fail to see how this problem is solved by putting the information
into a multipart parameter.
...
I also *really* don't like the notion of making the first part of the
multipart/attachment thingie special in some way. The contents should all be
attachments if this labelling is used. The initial descriptive material (or
whatever you call it) should be outside the multipart/attachment structure.
Making this choice once again leads to situations where we have a
multipart/attachment that only contains a single part. However, I still think
that the case of a message containing a single part that's an attachment is
going to be so common that any objection to this is tantamount to rejecting the
entire approach.
My bigger problem with this is that it assumes that the disposition of a
message is a binary condition -- either it is an attachment or it is not. I'll
willing to bet that there will be more of these distinctions eventually, and we
may even want to allow for more than one disposition for a single part. I think
that if we impose an implicit limit of this form now we'll regret it later.
Ned