To follow up on what Jacob Palme said ...
(...)
You are right. The embedded URL cannot be relative.
(...)
A person who receives a messages containing HTML may however often
be a person with a very limited mail system, which may have no
understanding at all of the Text/HTML Content-Type. The intention
with my solution was that even such recipients should be able
to read the HTML part, by saving it in a file, and opening it
with any ordinary Web browser.
Not so fast. Do not enslave HTML to HTTP. It is quite possible
to have MIME parts, as Keith has suggested, that are ephemeral,
included in the mail, and never served by HTTP. After all, one
mission for MIME is to be the Web by Mail. It has to work for
people who _only_ have mail.
In particular, when there is an ephemeral message-peculiar part a
scheme with embedded relative URLs matching to the
content-disposition _does work_ for your naive user. The user
has to get the parts manually into files named per the
content-disposition, but from there the separate WebBrowser walks
the bundle successfully, and independently from the existence or
non-existence of HTTP.
For a recipient with HTTP, it makes sense to branch to HTTP at
the earliest moment and multiparts are not particularly needed.
I confess to having a side conversation with Roy Fielding in
which he taught me that.
For any sub-part without an HTTP server behind it, relative URLs
and content-disposition appear to be the way to go. And this
could be the whole tree for certain audiences.
As I said at the outset, HTML and HTTP are used together but HTML
supports threading of content independent of the distribution of
the pieces. We don't want to break that.
Email still unites a far bigger internet than does HTTP, despite
the relative press interest.
Al Gilman