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 also have reservations about the requires/owner functionality.
An obvious alternative is to get rid of the "hidden" disposition,
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).
I would propose keeping hidden but removing the requires/owner stuff.
explain why it's better to have a content-disposition of "hidden"?
I would explain it in the context of presentatation states in the X
world. There a window is in one of three states:
X ICCC MIME
====== =============
Normal -> Inline
Iconic -> Attachment
Withdrawn -> Hidden
This provides a good mapping (excuse the pun) for the presentation
states that we could envisage for MIME objects. The semantics of
"hidden" do not involve the additional functionality described for
"owner" and "requires".
One example of why I would want to have the hidden state is in order
to handle new multipart types in a reasonable manner. If I have
various non-presentation parts interspersed in a multipart/foo that
then degrades to multipart/mixed they won't clutter up the viewer.
We would also like to be able to tack on a table of contents to a
multipart/mixed and not have it show up as a viewable element.
The question I would pose is not why we should have hidden but why
can't we decouple the traceability functionality of "owner" and
"requires" from the presentation functionality.
Gabe