To follow up on what Larry Masinter said ...
It's great you wrote this up. Now that I see it laid out, I'll argue
for removing the 'filename method' and instead suggesting that if the
text/html body part itself has a content-location, that the URL
contained within be considered the 'base' and that any relative URLs
(including those that look like filenames) be considered relative to
the particular base.
[deletions]
are equivalent. And we should consider whether
Content-Location: "url"
should be written using Content-Disposition, e.g., with:
Content-Disposition: inline; uri="url"
since the location presented is not *actually* the location of the
data, but rather the header says that you should treat the embedded
content AS IF it were at that location.
Basically, yes. The "uri=" parameter should be introduced into
the working parameter set for Content-Disposition, as a peer of
the "file=" parameter. This does not _eliminate_ the "file" method
because indicating the file disposition of multiparts is a more
general, desired feature for part types other than text/HTML; and
in the case of simple relative URLs it is sufficient.
I would like the Content-Disposition parameter dictionary also to
contain "base=" so that a relative URL can be indicated as the
disposition URI separately from a nominal base. I can possibly
be talked out of that if I can convince myself that leaving the
base-setting to the outer entity is robust enough. But basically,
I want to define headers that apply appropriately to an arbitrary
RFC 822 entity if I can, and not have different headers for
wholes and for parts if I can get away with it.
The relative URL would be set to include just enough of the
nominal absolute [as disposed] URL so that if it is not
satisfied, links within some of the pages are at risk of being
broken, but that other adjustments in the base are not at risk of
destroying links between the pages included in this MIME
multipart.
The "basically" qualifier is that without using Content-Disposition
as the context, a "Location:" or "Content-Location:" header
indicates the URI _at the source_ and not a disposition location.
So it is not an option. If we want to indicate a desired disposition
location in URI terms, it has to be something new and not "Location:"
or "Content-Location:" as they stand now.
Your plan seems to assume that the MIME multipart is composed for a
unique recipient and that the agent composing the multipart message
knows and has authority to determine the disposition of the parts
at the receiving side. Neither of these is generally true. It is
better to handle as well the more common case where some small
neighborhood of relative paths will be the same as disposed as it
was understood to the message composing agent, but that higher-order
path information will be determined at the receiving site.
Consider what happens in a typical software install. Some subtree
is reconstructed inviolate, but where it goes in the larger scheme
of things is just nominated by the installation package, and adjusted
as needed by the user.