Re: Multipart/alternate as root in Multipart/related

My reading of your comment
> In other words, we do need to kick the responsibility for
> supporting inter-part dependencies upstairs to Multipart/Mixed.
suggested that Mul/Mix needed changing.  Your current message seems to
indicate that all that is needed "for 1806 'Content-Disposition'" is
all that is needed.  If that's the case then I have no problem with
the multipart/mixed piece of this.

Thanks for clarifying the difference between content-Disposition and
content-Location.  After rereading 1806 I conclude that it tells the
MIME UA the following.

	If the UA is about to display this entity
		if the cDisp is INLINE then don't display it
		else if the cDisp is ATTACHMENT
			ask the user if she wants to see it
		otherwise ask the user if she wants to see it

	If the UA is about to store this entity
		the filename parameter is a suggested file name
		but not a directory location

I don't believe that that alone is sufficient to support an interrelated
set of entities because one doesn't know which entity of the set to
start with (pick a random from the entities w/o cDisp headers?) and
what software will be responsible for making sure the links are valid
on receiver's system.  How, in your view, will that happen and how
will it avoid having the UA know the internals of those types.

If your view requires tightening 1806 then it may be a good idea
to write it up as an Internet-Draft.

It is necessary as well, IMO, to distinguish between a MIME entity
Text/HTML and a interrelated set of entities that whose display
start with a Text/HTML entity.  That's one of the things that Mul/Rel
provides.

Ed

On Wed, 22 Nov 1995 13:58:28 EST Al Gilman wrote:
> ...  I don't yet see that there is a requirement for
> a named Multipart/Related type, or that if it is implemented as presently
> designed that I would want to use it.   I don't mind a few stray type
> definitions here and there, but I _do_ want disposition to work so
> I can get on with my job.
> 
>   All the intelligence about how to find the links and what to do with
>   them should reside outside the mail UA.  I call the piece that has
>   that intelligence the Receiving Agent, RA.  When Content-Disposition
>   is used I want to see the RA put the contents in a place where the
>   browser (more generally the helper application or display processor)
>   can readily find it.
>   
> The MIME-understanding part should understand the tree of parts it
> has decoded and honor disposition instructions marked up therein
> in accordance with RFC 1806 (and I want some future tightening and
> growth in this header as discussed earlier.)
> 
> If the MIME processor can do this, then the job of the Receiving
> agent can be handled today by the host file system and in the
> future by an enhanced data management service provided by the
> OS or desktop manager.
> 
> The RA is an option without likelihood of wide implementation.  MIME
> bids to be a niche player it it designs thus.
> 
> ...
>   
> Content-location tells you where the source had it.
> 
> Content-disposition, while not an authority above the user, tells
> you where the sender thinks it should be put.  Note the separate
> annotation of relative and base URIs to distinguish what is
> important from what is arbitrary in this advice.
> 
> ...

Received on Wednesday, 22 November 1995 16:19:00 UTC