On Thu, 2 Nov 1995, Keith Moore wrote:
a. what happens if you want to send things around without putting them
on a web server...say because they're for the private consumption of
the recipients?
I described what will happen for four different kinds of mail systems.
The two more advanced of them will have no problem. The two less
advanced may have problems. One solution would be to include a
secret key in the URL-s, so that only those who have this secret
key can retrieve the message from the Web server. I am no experts
on Web security, but I guess there are solutions for this.
b. what happens when the URLs become URNs? the distinction starts to
blur...
Would this cause any problem? As long as the URL/URN is the same in
the HTML text as in the Content-Location statement, this would work
okay. But perhaps "Content-Location" should be named "Content-Name"
or "Content-URN" in case it contains a URN and not a URL?
Perhaps "Content-URL" and "Content-URN" would be better names
than "Content-Location" and "Content-Name"?
one alternative to content-location is to use content-disposition
and ordinary filenames (perhaps of the xxxxxxxx.yyy variety).
then "multipart/related" tends to mean "store all of these filenames
for your children in an otherwise empty temporary directory" and the
HREFs can refer to those filenames as if they were relative URLs .
This isn't as aesthetically pleasing as using cid's, but it appears
to be much easier to implement ... there's no need to define an interface
to allow viewer programs to open things by content-id (presumably they
can already open files).
That sounds reasonable as an alternative. It would require less
modifications to mail systems than CIM-s. It would however be useful
to have the original Content-Location available also. That would
allow local mail systems to purge images to save disk space, knowing
that the images are available on the original server.
maybe the compromise is to let multipart/related take an additional
parameter that describes which of the methods (cid, url, filename)
its children might use.
Standards should preferably not describe too many alternative ways
of doing similar things. But I am not wholly again your idea. What
do other people think?
------------------------------------------------------------------------
Jacob Palme <jpalme(_at_)dsv(_dot_)su(_dot_)se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme