- From: Keith Moore <moore@cs.utk.edu>
- Date: Wed, 22 Nov 1995 14:10:15 -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
> 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
Received on Wednesday, 22 November 1995 14:11:56 UTC