Re: Multipart/alternate as root in Multipart/related

Keith Moore (moore@cs.utk.edu)
Wed, 22 Nov 1995 14:10:15 -0500


Message-Id: <199511221910.OAA03945@wilma.cs.utk.edu>
From: Keith Moore <moore@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,
Subject: Re: Multipart/alternate as root in Multipart/related 
In-Reply-To: Your message of "Wed, 22 Nov 1995 13:58:28 EST."
             <9511221858.AA19085@severn.wash.inmet.com> 
Date: Wed, 22 Nov 1995 14:10:15 -0500

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

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.

Keith