W3C home > Mailing lists > Public > uri@w3.org > November 1995

Re: Multipart/alternate as root in Multipart/related

From: Keith Moore <moore@cs.utk.edu>
Date: Wed, 22 Nov 1995 14:10:15 -0500
Message-Id: <199511221910.OAA03945@wilma.cs.utk.edu>
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
> 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.

> 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.)

You seem to assume that the message is decoded before it is presented.
MIME was designed to allow (in most cases) decoding and presentation
on-the-fly -- certainly for multipart/mixed.  Multipart/alternative is 
a special case in that it requires the user agent to do some look-ahead
to know which of the components to select.  Multipart/related serves
a similar purpose -- to let the decoder know that additional processing
is required (to remember content-ids and associate them with files) while 

The more I think about it, the more I'm sure that putting cid= 
functionality in multipart/mixed is a show stopper.  It's too 
incompatible with the installed base.

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

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:32 UTC