Re: Multipart/alternate as root in Multipart/related

To follow up on what Ed Levinson said ...
  
  Putting intelligence into Multipart/Mixed should be resisted.
  Strongly resisted.  Either Mul/Mix gets retrofitted so it knows when
  the contained entities should be treated as a nodes in a graph of
  related entities, or you cannot count on the receiver doing what was
  intended.  That's why Multipart/Related.
  
You have simply stated what you want to do as a requirement without
any justification.  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.

  For some envirionments that may be doable without modifying the
  message entities.  Whatever mechanism we choose we should not require
  either that the entities be change or that they be stored in specific
  places.  IMO, the Content-Disposition is useful only in that it tells
  me where the sender got or stored the entity.
  
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.

For future dispositions into a Web Cache, I refer you to Larry's
comments that a dispository URI would be preferable to either
Content-ID URIs or limiting disposition to files.  Since file=
disposition nomination is the general case for both HTTP and
other file clusters (although in terms of the broad range of file
systems is only expected to work within a flat, single-folder
namespace), that too should be supported into the long term in
parallel with URI-designated disposition advice.

Think again.  You'll thank me eventually.

Al

Received on Wednesday, 22 November 1995 14:00:11 UTC