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.
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.
You're right about applying the content-disposition hack to existing
HTML documents that weren't written with this in mind. But even then,
if you're comparing two solutions A and B, where
+ A requires *users* to install a program that rewrites HTML to
map internal document identifiers to local filenames, and
+ B requires *providers* to install a program that rewrites HTML
to map internal document identifiers to relative filenames
....I think it should be obvious which one is easier to deploy and is
more likely to gain acceptance.
(assuming, that is, that support for content-disposition is already
being developed/deployed)
Some environments might require that but to impose it on everyone is a
"bad idea". After taking the html out of the mail message there's no
way to come back and check with the sender to see if it is correct.
I don't know what "correct" means in this case. If you want integrity
and authenticity verification for documents sent via email, MOSS/PEM
or PGP are well suited to solve that problem. If you want the
recipient to see the "current" copy of the document, he's going to
have to contact the authoritative server anyway (though he may be able
to do a check of last-change-date or md5 hash or some such and avoid
downloading the entire document). But "correct" and "current" aren't
the same thing -- the "current" version of the document is not always
the "correct" one for the recipient's needs.
Keith