To follow up on what Keith Moore said ...
re: linking things with URLs and Content-Location under multipart/related:
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?
The scenario you paint is good for this.
b. what happens when the URLs become URNs? the distinction starts to
blur...
That's only good.
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).
File URLs referring to the files implied by the disposition
markup sound like what you want in this case. Yes.
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.
Who needs this? If you let them use 'em all, they are syntactically
distinct and it all works. The extension to disposition-related
file URLs is compatible.
Al Gilman