b) within a multipart/realted, use content-disposition's filename to
indicate the name of the file (relative to a temp directory).
within a multipart/related, files would automatically be stored
and sub-directories would be automatically created, but there
would be some restrictions on the kinds of file names that would
be allowed.
This is fine but using "cid:" urls inside the HTML to point into
other message bodyparts should still be included as experimental.
We have already implemented this and its straight forward. To me
Keith's approach is the no short cut way of implementing links to other
body parts.
It's not difficult to implement cid URLs if you have control over both
the mail reader and the browser. It's very difficult to implement
cid URLs if you don't have such control, and there is no standard
for how MIME mail readers define the content-id to file name
mapping for HTML browsers.
I'm all for having cid URLs PROVIDED someone defines this interface.
It should be relatively system independent and also be able to deal
with nesting (multiple levels of multipart/related).
Also these "... some restrictions on the kinds of file names..."
sounds like a HACK, and smells like a HACK. Such an approach is not
required with the straight forward "cid:" approach.
If you're going to let the sender specify a file name, and the
recipient's mail reader is going to unconditionally/automatically
store a file under that file name, you'd better have some well-established
conventions for what sorts of names are legal. Obviously the
receiving system is going to want to put those files in a directory
of its own choosing, outlaw relative paths (e.g. "../../../../CONFIG.SYS"),
etc, so we get much better interoperability if we establish rules
for the kinds of things that senders can expect receivers to allow.
As for whether it's a "HACK"...I prefer to think of it is using
an interface that's already defined and implmented instead of
creating a new one. This is the way the world works - water
takes the path of least resistance when flowing downhill.
If you don't want to flow down a certain path, it's going to
take lots of work to divert it, so there'd better be a good
reason why.
I do prefer reference by content-id for aesthetic reasons, but
I also recognize the value in letting body parts reference each
other by filename. (as far as I know I was the first to propose
both methods, so I like them both :)
f) for the time being, we punt on [Content-]{Base,Location,UR{L,N,I}}
for MIME email. We open a huge Pandora's box when we try to
blur the line between "things that are included in an email message"
and "things that are externally accessible". We already have one
very similar Pandora's box with "the URN problem"; we don't need
another one just yet, and we don't have to solve the general problem
in order to provide a very useful facility.
I don't know about other mail clients but with mine I can drag any HTML
page off of the net and mail it. Now most HTML pages I have seen have
relative URLs embedded in them. If I don't have a Content-Location header
to carry along with that HTML bodypart then the HTML can not be viewed
properly. This is a real problem and we are not just going to ignore it
now.
I don't have a problem with this particular use of Content-Location
(or Base, if you prefer). But let's call it "base", and let's make
it a parameter to the html content-type rather than a general MIME
header. This helps preserve the notion that it's an HTML-specific
facility to support relative URLs, rather than the notion that it
applies to any body part. I'm concerned that people will interpret
Content-Location as "you can get the current copy of this file
from this URL", which just encourages people to cache the URL->file
binding without any kind of integrity, authenticity, or currency
assurance.
Keith