- From: Ed Levinson <elevinso@Accurate.COM>
- Date: Wed, 22 Nov 1995 15:48:07 -0500
- To: asg@severn.wash.inmet.com (Al Gilman)
- Cc: elevinso@Accurate.COM (Ed Levinson), moore@cs.utk.edu, jpalme@dsv.su.se, jpalme@dsv.su.se, ietf-types@cs.utk.edu, uri@bunyip.com, elevinso@Accurate.COM
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