Re: The TEXT/HTML Content Type in e-mail

If you want to extract HTML from the web and send it along in mail,
you should note that many embedded URLs are relative, not absolute.

Your 'content-location:' proposal makes less sense when the URL is
relative. Also, if you want to embed a VRML document inside a HTML
image, and the VRML document has embedded URLs too, you might not want
to nest them, and if they're not nested, the content-location doesn't
give enough context to rename the URLs in the first part.

You claim for: "New notation using Content-Location" that
"The user can manually save the Text/HTML content in a file, and open
and view it with an ordinary Web browser." but this isn't any more the
case for your new notation than the old, except when the URLs point
with absolute links to resources that are externally available.


You say that for "Mail system which uses a proxy HTML server" that
using content-location, "the proxy server will recognize that it has
the picture locally and not retrieve it from its remote location", but
as we've discussed already, accepting the word of a mail sender that
the content supplied with a mail message is actually a valid cached
copy of a given URL is insecure, and subject to abuse. The only case
where this is at all reasonable is in fact where the URL is a
semantically neutral one like a content-id!

While I'm sympathetic to the idea that we should leave the HTML alone
and not modify the URLs within it, I think that the renaming could
well be done in a prefix or wrapper to the HTML containing the
to-be-renamed URLs, and leave the individual parts of the /related as
identified by content-ID rather than some 'content-location' that
contains relative addresses.


Two minor nits:

1) in your example,


      <IMG SRC=HTTP://www.dsv.su.se/picture.GIF>

 should be
      <IMG SRC="http://www.dsv.su.se/picture.GIF";>

  with 'http' lower case and the whole URL in quotes.

2) You say "Mail system which uses a proxy HTML server" when I think
you mean "proxy HTTP server".