"when interpreting relative URLs in a MIME multipart, the message
should be regarded as a directory, with each part being a file named
by its Content-ID. Multipart content-types are represented as directories".
Be very careful about the specification. Using directories
to hold the several parts of any multipart object is wonderfully convenient,
but (don't laugh) some systems don't support directories or restrict the
creation/destruction of directories. So take care that you don't presume
too much when writing the spec. Thanks!
of an adjoining multipart, or even <a href=../content-2(_at_)msg> to refer
to a body part that is adjoining the parent multipart.
The "parent" syntax used by UNIX proved to be a real problem
for Anonymous FTP URLs. Many FTP servers lose state such that they
don't have a concept of a "parent directory". It could be a problem
here too, because any given object may not "know" that it is part of a
multipart. And as Dirk pointed out, the "path" part of the URL
could be *anything*.
Don't let me be a stick in the mud. We're on the right track.
Just watch out for those land mines in this swamp.
--
Rick Troth <troth(_at_)ua1vm(_dot_)ua(_dot_)edu>, Houston, Texas, USA
http://ua1vm.ua.edu/~troth/