Re: Multipart/alternate as root in Multipart/related

Keith Moore (moore@cs.utk.edu)
Wed, 22 Nov 1995 00:57:48 -0500


Message-Id: <199511220557.AAA02698@wilma.cs.utk.edu>
From: Keith Moore <moore@cs.utk.edu>
To: asg@severn.wash.inmet.com (Al Gilman)
Cc: moore@cs.utk.edu (Keith Moore), jpalme@dsv.su.se, elevinso@Accurate.COM,
Subject: Re: Multipart/alternate as root in Multipart/related 
In-Reply-To: Your message of "Tue, 21 Nov 1995 15:52:40 EST."
             <9511212052.AA06831@severn.wash.inmet.com> 
Date: Wed, 22 Nov 1995 00:57:48 -0500

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

[...]

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

This doesn't follow from your argument.  I believe that there is a
need for some MIME parts to be able to reference other MIME parts and
external objects, but you haven't demonstrated that MIME UAs should
provide this ability for components of a multipart/mixed.


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

For the long term I'd want a system that used the anticipated URN
resolution infrastructure.  In other words,

(a) allow MIME objects to make references to other objects by URNs (or
LIFNs),

(b) allow MIME messages to contain cached files (perhaps marked with
"Content-Disposition: cached-file; LIFN={lifn-for-that-file}")

(c) allow MIME messages to contain "URCs" (more specifically, bindings
from URNs to LIFNs or content-IDs, along with an expiration dates for
those bindings and possibly digital signatures).  Whatever is used
here should be the same data structures used for URCs in general.

So the included file referenced by URN would be treated as a *cached*
copy of the file associated with the URN, along with information that
says for how long the cached copy is valid.  

This would integrate very smoothly with the URN resolution mechanism,
since the client would just read the URC and/or associated file into
its cache and present the MIME objects normally.  If the included
files in the mime message were current, it would present them (since
they'd already be in the cache).  If the files in the MIME message had
expired, the client could attempt to fetch them through whatever means
it used to fetch other URNs.

Even if URLs were used instead of URNs, I'd still want to treat the
included files as cached copies to back up the *real* file. 

Keith