Re: Content-Disposition Header

[Gabe Beged-Dov <gabe@xxxxxxxxxxxxxxxxx>]

> 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