Re: Recursive look up of base in outer headers

Al Gilman (
Mon, 1 Sep 1997 10:46:17 -0400 (EDT)

From: Al Gilman <>
Message-Id: <>
Subject: Re: Recursive look up of base in outer headers
To: (Jacob Palme)
Date: Mon, 1 Sep 1997 10:46:17 -0400 (EDT)
In-Reply-To: <v03007811b03029e30580@[]> from Jacob Palme at "Sep 1, 97 10:26:01 am"

to follow up on what Jacob Palme said:
> Does your statement answer the question on which has highest
> priority in deriving the base, an inner Content-Location or
> an outer Content-Base?

On the one hand, no, my previous message said nothing on this

On the other hand, I don't think that there is a problem in this
area.  The remarks that follow are based on a broad concept of
how things should work which I believe is consistent with RFC 1808.
They are not based on a close, lawyerly reading of 1808.

As I understand it, the statement that 
	The BASE implied by attributes asserted on an
	inner scope [e.g. in MIME multipart hierarchies]
	takes precedence over a BASE derived from such
	attributes attached to an outer scope.

is, for RFC purposes, equivalent to saying
	Search outward to successively wider horizons
	until you can establish a BASE.

If the MHTML RFC were to assert the "inner scope takes priority"
rule I do not expect this to conflict with the provisions of
RFC 1808 and its successor language in the generic specification
for URLs.

As for the specific example you quote, yes, an inner
Content-Location would take precedence over an outer
Content-Base.  Content-Location and Content-Base attributes are
equivalent in this rule application; they both imply a BASE in
the context of HTML documents within the associated MIME part
hierarchy scopes.  Neither attribute has priority by reason of
whether it is a base or location indication.  However, within the
class of attributes establishing a BASE, the assertion raised
most locally takes precedence.

> Does this mean that people are mapping directory structure to MIME
> multiparts? For example, if you have a directory structure:

No, as I think about it, you could argue either way from what
is happening in HTTP because attributes are beign migrated from
enclosing scopes in the archive to the atomic HTML file for
transmission.  But that is because only one file is being sent.

I should probably confess that my support for the "accept BASE
inheritance from up the tree" notion is more of a general 
philosophy.  That philosophy is, roughly, that since the 
transmitted multipart tree has a reliable hierarchical structure,
and people are generally used to hierarchical archives, that we
should make the received multipart hierarchy work like a slice
of archive mounted locally, so far as we reasonably can.

Maybe a more direct, and compelling argument is that the BASE
notion comes out of the part of URL structure which is consciously
hierarchical.  BASE is a starting node in a tree context.  As
such, it is natural for the default assumption to be that the
part-tree in the message can be BASEd once at the root, or 
explicitly re-BASEd piecewise if one BASE will not do.

Al Gilman