Basically, I really like this document. I have no problem at all with
the inline/attachment stuff, and I think the hidden/requires/owner stuff
is a very clever approach to the compound object problem.
I am concerned, however, about linearity of processing. There are lots
of implementation strategies in the world for MIME, and I'm intimately
involved with two radically different ones, Andrew's and metamail's. I
think this stuff is all relatively easy to implement from Andrew's
perspective, where a process can churn for as long as necessary before
producing an integrated display in a window. But things are tougher for
metamail. Metamail basically views the world as a pipe, with raw MIME
coming in one end and a user on the other. What should metamail do when
it gets a body part that has a type of "hidden" and an owner reference
to something it hasn't seen yet, and thus can't know whether or not it
can process?
I guess the answer is that such linearity is simply not possible in this
model, and that metamail should start caching "hidden" body parts until
it is done, making them available to their owners as necessary, and then
display as attachments all the hidden parts for which the master wasn't
displayed. This can be done, but it is a fair bit of work.
An obvious alternative is to get rid of the "hidden" disposition, and to
go back to the proposals for a multipart/related or something like that.
Here we'd have a clear owner/owned relationship implied by the
multipart subtype (you could say something like the first or the last
thing is always the owner). This would be a lot easier to implement in
metamail, at least, and probably in other MIME readers, because most
people have understood that you need to be really flexible about adding
support for new content-types; the "hidden" stuff requires a whole new
kind of functionality for existing types, which will be much harder for
some implementations. (I don't think this applies to the
inline/attachment distinction, because systems with inline semantics
probably already have attachment handline built-in, and can take the
hint. And I'm not sure that systems that view the whole world as
attachment-based are even going to implement the "inline" semantics, so
this doesn't strike me as a big implementation hit, though I could be
wrong.)
I'm sure I can implement this either way, but I'm just not sure that the
"hidden" stuff really belongs in content-disposition, and I am sure that
the multipart/related idea would be easier to implement. Can anyone
explain why it's better to have a content-disposition of "hidden"?