I do not think it should be done this way; I much prefer the addition
of another header, as I indicated earlier. I like Laurence Lundblad's
name; "disposition". How about:
disposition := "Content-Disposition" ":" location
location := "inline" / "attachment"
I like this model a lot. I had originally envisioned this as a parameter on the
Content-Type line, but when you get right down to it this has nothing to do
with the type of the contents; it is instead an indication of how the content,
regardless of type, should be handled. It therefore makes a lot of sense to
handle this as a separate entity.
You've come up with the same two dispositions I've thought of. This set may
need to be extended in the future and we should allow for that.
I think this makes stuff more general than creating a subtype of
multipart. It does have the unfortunate consequence of making a change
to the spec, though. Do y'all think this change is substantive enough
to block it's acceptance? How about if it was trated as a 'hint',
instead of as dogma?
The MIME specification already allows for additional Content- headers. This
merely provides information about how to handle a part of a message. It is
therefore not a change at all; it is an extension. It can also be described in
a separate document; I think it probably should start out this way.
Nevertheless, I do view this as a hint of sorts -- for one thing, many gateways
will not be able to handle things differently based on disposition information.
Furthermore, reasonable user agents should probably provide a means to override
the specified disposition. Nothing is more irritating than wanting to check out
a file attachment with a viewer but the user agent won't let you!
The problem I have with the multipart/attachments thing is, as
proposed, you could not have both attachments and in-line bodyparts in
the same message.
You could, but only at the expense of adding extra structure. I'd prefer
to keep the structure separate from the disposition; I don't like seeing
structure coupled to disposition.
Ned