I agree with most of what Keith Moore says except the following:
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.
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.
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.
