Argghhhh........
it seems that we need *two* mechanisms:
1) mimemail:content-id - for absolute reference to this content, and
no other. Might even be used for reference to parts of *other*
messages!
2) mimemail:relative-path - for reference to another part of the same
message, whether it uses Content-ID: or not.
(See part 3 of the enclosed message)
The current draft of the relative url spec
(draft-ietf-uri-relative-url-01.txt) has this to say:
| 3. Establishing a Base URL
...
| 3.2 Base URL within Message Headers
|
| For access schemes which make use of message headers like those
| described in RFC 822, a second method for identifying the base URL
| of a document is to include that URL in the message headers. It is
| recommended that the format of this header be:
|
| Base-URL: absoluteURL
|
| where "Base-URL" is case-insensitive.
It's possible that, in the message/external-body context, this
mechanism could be used to specify the base URL. Base URLs can also
be specified in the HTML document itself. If no base is specified by
either mechanism, the enclosing message could be assumed.
Unfortunately, the next section of the draft says some things which
mess this idea up:
| 3.3 Base URL from the Retrieval Context
|
| If neither an embedded base URL nor a "Base-URL" message header is
| present, then, if a URL was used to retrieve the base document,
| that URL shall be considered the base URL.
If an external body access-type of URL is defined, this would cause
inconsistency: a text/html external body retrieved by access type URL
would be handled differently from one retrieved via FTP.
Alternatively, a "Mime" access scheme could be defined so that a Base
URL of "the enclosing message" could be specified explicitly (Harald,
I think this is close to what you're proposing above).
---glv