There are several issues mixed together in Jacob's message all of
which need to be addressed. First, though, let's separate them out.
1) References to existing URLs (i.e. available from HTTP
servers) in WebEmail text/html
2) The appropriate use of the cid (and mid) urls
3) Providing for alternate representations
The first two seem straight forward and I'll address them here. The
third deserves its own thread.
Naturally text/html entities could refer to any URL, but what if you
want to include it in the message. In that case the referred to entities
should be made available to the Web browser / MIME helper application.
IMO, through the browser's cache. Jacob suggests this behaviour.
The mechanism for providing a server location for those Web elements
included in the MIME message could be Content-Location as Jacob
proposed or Content-Disposition as Keith suggested. I prefer the
latter and would have the file name be a URL. Does anything prevent
that? Rfc 1806, Content-Disposition says
The receiving MUA should not respect any directory path
information .... The filename should be treated as a terminal
component only.
In theory a URL is opaque and thus qualifies as a "terminal component".
In reality we all recognize the details for what they are.
Keith points out that the cid/mid urls provide for private messages
that work as web pages. He points out that at some point the referred
to entities need to be reduced to filenames on the recipient's system.
That implies the main page, the text/html entity, must be edited to
convert the cid/mid to file names. Unless, of course, the browser can
process the MIME message.
In both these cases Multipart/Related provides some useful service in
collecting the Web page elements into a single entity and providing a
processing model. In particular, draft-ietf-mimesgml-related-03
posits a Receiving Agent (RA) that can perform the services of moving
the included, but web served, images into the browser's cache or,
if needed, transforming the cid: urls in the text/html into file: ones.
Dealing with alternates, however, thread of another color.
Best.../Ed