I agree that this is getting confusing. We need to limit our scope.
I STRONGLY suggest that we narrow our immediate efforts to defining
a way for MIME body parts (html and sgml in particular) to reference
external objects, WHICH ARE DEFINED WITHIN AN ENCLOSING MULTIPART/RELATED
construct. I further recommend that we choose a strategy that assumes
a minimum of modification to existing html, etc. viewers.
In the long term, we may eventually have a URN resolution infrastructure
that facilitates resolution of arbitrary URNs. Until we do so it's not
very useful to try to define content-id and/or message-id URIs in such
a way that they can reference things outside of a limited context that
we control. (If someone wants to provide a message-store service that
looks up messages by message-id or MIME body parts by content-id, without
trying to delegate the service to the original authors of messages, the
current content-ids and message-ids will suffice for this purpose.)
So let's define something that we can implement now, and have it be
useful without any additional middleware or infrastructure.
Keith
---
p.s. As a strawman, I suggest:
a) define a multipart/related (or whatever you want to call it) type
that indicates that: (a) its components are to be associated with
filenames before presentation (probably by storing them in ordinary
files), and (b) the content-id of the "start" component.
b) within a multipart/realted, use content-disposition's filename to
indicate the name of the file (relative to a temp directory).
within a multipart/related, files would automatically be stored
and sub-directories would be automatically created, but there
would be some restrictions on the kinds of file names that would
be allowed.
c) HTML documents can use relative URLs to access files which were included
in the multipart/related. Assuming that the start parameter of the
multipart/related points to an HTML document, the HTML viewer will
be passed the filename where that document was stored, and the viewer
will resolve any relative URLs in the document using that context.
SGML documents will use their normal mechanisms to associate
internal document identifiers with external filenames.
(apologies for not using the proper SGML lingo)
d) a message/external-body can be used as one of the components
of a multipart/related. the message/external-body can have
an access-type of URL. this might mean that the message/
external-body will be fetched before the content is presented;
though implementations would be free to associate the URL of the
external body part with a special "file" such that the body part
is loaded on demand when the "file" is opened. (obviously this
would be highly system dependent)
it would therefore be possible to ship an html document containing
lots of relative URLs, while including the actual documents corresponding
to some, but not all, of those URLs -- the other relative URLs would
point to message/external-body parts with access-type URL, pointing to
the absolute URL.
e) a multipart/alternative can be a component of a multipart/related.
(the minimal implementation of multipart/alternative still
applies -- nothing forces the viewer to pick the "best" alternative.)
f) for the time being, we punt on [Content-]{Base,Location,UR{L,N,I}}
for MIME email. We open a huge Pandora's box when we try to
blur the line between "things that are included in an email message"
and "things that are externally accessible". We already have one
very similar Pandora's box with "the URN problem"; we don't need
another one just yet, and we don't have to solve the general problem
in order to provide a very useful facility.