Glenn,
it is important to be aware of context when you are looking at the
relative-URL doc.
The *normal* case of a relative-URL is the one you quote from section
3.3: That the base URL is the one you used to access the document.
This is true, and the different handling depending on context is precisely
what gives rise to the problem. Am I missing something?
Suppose I have an HTML document containing relative URLs which is accessible
via ftp. If I send a reference to you like this:
Content-Type: message/external-body;
access-type=url;
url="ftp://ftp.utdallas.edu/glv/my-boring-bio.html";
then section 3.3 is applicable, because it says "if a URL was used to retrieve
the base document ...". But if I send it to you like this:
Content-Type: message/external-body;
access-type=anon-ftp;
site="ftp.utdallas.edu";
directory="glv";
name="my-boring-bio.html"
then section 3.3 is *not* applicable, because the base document was not
accessed via a URL. In this case, the base URL would default to the
empty string (section 3.4).
All of which just goes to say that external bodies combined with relative
URLs are sort of problematic. External bodies are strange anyway, and they
seem to be used for two distinct purposes: to save bandwidth on large parts
of an integrated message (e.g., "Barbershop MIME"), and to send pointers to
entirely separate documents which are not meant to be integral to the MIME
message (e.g., the RFC announcements).
---glv