Ed Levinson wrote...
> It's good we're now speaking from the same script. Thanks.
>
> As I understand Keith's suggestion, it requires replacing the URLs in
> a message with local file names. I.e., it *requires* altering the
> text/html body part. I am opposed to any solution that imposes
> such a policy.
Keith Moore responded ...
This wasn't exactly what I had in mind. My idea for using
content-disposition was that it would allow you to *write* html that
worked in both an emailed environment and on a web server, by using
particular kinds of relative URLs and by restricting the kinds of file
names used.
The way I see it, the URLs in the message are not required to be
either all local or all global. In fact, for those objects which
are served on a persistent fashion by some server, the global URL
is to be preferred.
The device of saying that the disposition should bind before any
URLs in the message are exercised completes the URL namespace for
miscellaneous message-unique MIME parts not persistently served
from the source. The filename restrictions were only for the
disposition header, which gives the MIME part a temporary home,
in the grander scheme of things.
An upgraded MUA can sense the presense of a local cache. The
MIME parts then have a disposition to be a cached copy of the
remotely served URL, for global URLs, and local files for
relative URLs.
For unchanged MUAs which only pass the HTML part to an HTML
engine, the globally addressed URLs are functional, if
inefficient. The copy [of content of URL] in the multipart
message may be overlooked.
The ony thing that doesn't work without modifying the MUA to
understand Multipart/Related is the references to message-unique
parts; This was not going to work under the access=cid propoal
until the MUAs were upgraded to cope, anyway. So we haven't lost
any ground on that score.
Al Gilman