Re: Multipart/alternate as root in Multipart/related

SUMMARY

Keith Moore opined:

  Unless there is a strong consensus that MIME body parts need to be
  able to reference one another in the general case, I'd recommend that
  this capability be limited to body parts enclosed in a
  multipart/related container.

  (And if there *is* a strong consensus that MIME body parts need to be
  able to reference one another, we'd probably want to build
  multipart/related into MIME itself...but such a change surely would
  bump MIME back to Proposed.)

This is one man's opinion, not a strong consensus, but the bottom
line is that MIME body parts do need to be able to refer to URIs,
Content-IDs are about to be URIs, and we _do_ need to provide better
support to multipart interdependencies than this proposal does.

The good news is that a better solution is easier, and very
continuous with the way things are now.

REQUIREMENTS ARGUMENT

MIME parts need to be able to refer to things (peer parts and
external objects) by URI.

We are in the process of making a CID a URN which is a URI.

This is the long-term track.  In the short term, tightening up on
the file disposition semantics will give us a way to get started.
I have already floated a design sketch for this on the list.

Clusters of HTML pages are a good example of a multipart which
has a graph of mutual dependencies but not necessarily a root 
part.  And they have more natural ways to refer to one another
than by CID.

This is a common pattern.  There are many filesets which graph
together by dependencies but where losing one file does not
invalidate all received files.  Even an SGML document is pretty
usable with a style sheet missing, or so.

In other words, we do need to kick the responsibility for
supporting inter-part dependencies upstairs to Multipart/Mixed.

The steps to do this are upward-compatible and nondestructive.
There is a way to put MIME on the right track to capture the
generic URI technology without reversion in status. 

DETAILS

Two versions of the example

Short-term encoding

multipart/mixed  {
	1: image/gif (Content-disposition: attachment ; file=neat.gif )
	2: multipart/alternative {
		text/plain (Content-Disposition: inline; 
				including text reference to neat.gif and
				that the GIF is the first part of this MIME
				message)
		text/HTML (Content-disposition: inline; file=me.html;
			embeds relative URL referring to ./neat.gif)
	}
}

Long-term encoding:

multipart/mixed (Message-ID: message-unique@node..net) {
	1: image/gif (Content-ID:<BL8V3T@node..net> 
		      Content-Disposition: attachment;
			uri=./neat.gif;
			base=file://localhost/anypath/to_here)
	2: multipart/alternative {
		text/plain (Content-Disposition: inline; 
				including text reference to neat.gif and
				that the GIF is the first part of this MIME
				message)
		text/HTML (Content-disposition: inline; file=me.html;
			embeds URN of
			mid://node..net/message-unique?BL8V3T 
					; or whatever the cid URN syntax is)
	}
}

NOTES:

1. The function of an access-method parameter in a Message/External-body
and the scheme designator in an URI overlap.  The continuous way to handle
this is to add processing of the URI in a Content-location: header, 
allowing this to fill in for the access-method if absent.


>From ietf-types-request@uninett.no Tue Nov 21 14:47 EST 1995
Return-Path: <ietf-types-request@uninett.no>
Received: from aun.uninett.no by severn.wash.inmet.com (5.x/SMI-SVR4)
	id AA06236; Tue, 21 Nov 1995 14:47:36 -0500
Received: from CS.UTK.EDU by aun.uninett.no with SMTP (PP);
          Tue, 21 Nov 1995 20:26:52 +0100
Received: from wilma.cs.utk.edu by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) 
          id OAA19813; Tue, 21 Nov 1995 14:26:46 -0500
Received: from LOCALHOST by wilma.cs.utk.edu with SMTP (cf v2.11c-UTK) 
          id OAA01199; Tue, 21 Nov 1995 14:26:43 -0500
Message-Id: <199511211926.OAA01199@wilma.cs.utk.edu>
X-Uri: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: Jacob Palme <jpalme@dsv.su.se>
Cc: Ed Levinson <elevinso@accurate.com>,
        Jacob Palme <jpalme%dsv.su.se@princeton.edu>, ietf-types@cs.utk.edu,
        moore@cs.utk.edu
Subject: Re: Multipart/alternate as root in Multipart/related
In-Reply-To: Your message of "Tue, 21 Nov 1995 12:16:13 +0100." <Pine.SUN.3.91.951121121414.9137D-100000@ester.dsv.su.se>
Date: Tue, 21 Nov 1995 14:26:36 -0500
Sender: moore@cs.utk.edu
Content-Type: text
Content-Length: 2969

> > My own interpretation is that 2 means Multipart/Mixed.  So
> > I'd write the Mul/Rel differently.
> > 	Mul/Alt {
> > 	    Mul/Mix {
> > 		Text/Plain
> > 		Image/GIF
> > 	    }
> > 	    Mul/Rel; type=Text/HTML {
> > 		Text/HTML
> > 		Msg/Ext-bod; access-type=Content-ID
> > 		    (points to Image/GIF above)
> > 	    }
> > 	}
> > This approach doesn't require creating a general Text/Plain compound
> > object.  It says if you can't handle Mul/Rel-Text/HTML just use
> > Mul/Mix.  That may even have benefits for allowing the installed base
> > to operate reasonably.
> 
> +------------------------------------------------------------+
> ! That was a neat idea! I will rewrite it that way if no one !
> ! else has any objection!                                    !
> +------------------------------------------------------------+

I'm dubious about this one.  Part of the reason you need
multipart/related in the first place is to give a user agent a clue
that the enclosed body parts might want to reference each other by
content-id.  To my knowledge, existing user agents don't provide any
way to do this, so they would have to add this capability to support
multipart/related.  Existing user agents could always add on a
multipart/related module that stored all components in local filenames
(and provided a well-defined mapping from content-id to filename),
before actually presenting the components of the multipart/related.

But having things within a multipart/related reference things outside
of the multipart/related container breaks this model.  It effectively
requires MIME user agents to store components in files and maintain
the content-id->filename mapping just in case some body part will want
to refernece another one.  

Keith

p.s.  For the (text,html) + gif case, I'd do the following:


in other words, the document is either:

+ an html document with reference to a gif file, OR
+ a two-part document with a text portion and a gif portion

rationale: we already seem to have the principle that any component of
a multipart "family" can be represented by multipart/alternative with
different representations. (as in multipart/security,
multipart/report), so I think it's entirely appropriate that the start
portion of a multipart/related have the same capability.

Received on Tuesday, 21 November 1995 15:54:07 UTC