You're correct in finding cDisp less appealing when dealing with
relative URLs. That's why I'd require the sender to provide absolute
ones. How else could we deal with one message containing two text/html
entities both of which contain "<IMG HREF="todays_comic.gif"> but
different BASE values?
Wait. You have two choices when mailing an HTML document that
originally contained relative links, but including the referenced
documents in the mail:
A. rewrite embedded URLs
B. don't rewrite embedded URLs
In case A, you have two choices:
A.1. Change the embedded URLs to "cid:...." and include
the content identified by content-ID:.
A.2. Change the embedded URLs to only use absolute links.
(This is what you're requiring above), and then
identify the actual location of those URLs as
content-location or content-disposition.
In case B, you must indicate somewhere how the embedded URLs link up
to the actual data supplied in the multipart/related stream. There are
two choices:
B.1. Identify the correspondence between embedded URLs and
content-ID by a table/catalog/etc.
B.2. Identify the correspondence between the embedded URLs and
the other parts of multipart/related by including
content-location or content-disposition, but letting
the disposition be a relative address.
I think if you're going to bother rewriting the HTML to change the
nature of the links, you might as well change it to use "cid:" links
on the sender side.
If you're not going to rewrite the HTML, B.2 looks like it is simpler,
but has the problem that the interpretation of the header of an
individual part of the multipart/related depends on information that
is outside of the part. This was a problem with multipart/form-data
also, and something that I struggled with.
I think we're better off with B.1., except that we need to invent the
format of the table.