Re: Recursive look up of base in outer headers

[Pete Resnick <[e-mail]>]

On 9/3/97 at 3:19 PM -0500, Einar Stefferud wrote:

>From Andy Jacobs's message Wed, 3 Sep 1997 12:11:01 -0700:
>}
>}> The MHTML standard says that if there is both a Content-Base
>}> and a Content-Location header in the same content heading, the
>}> Content-Base has precedence over the Content-Location.

Which makes sense. We all know of documents who specify a base that is
vastly different from their location. You're not supposed to do that, but
people do all of the time.

>}Why not specify that if both headers exist (which is the only case where
>}precedence matters) then the Base and Location headers will be combined
>}according to the [RELURL] rules.  This would be consistent with the body
>}part matching that already has to be done by MHTML readers.
>}
>}Another way of saying the same thing would be to say that Location has
>}precedence if it is an absolute URL, and if it is a relative URL then it
>}is combined with the Base.

This sounds even more confusing than either of the other choices. Now
you're saying I have to take a relative Content-Location and add it to the
Content-Base in order to figure out the base of the document. What if the
Content-Location has ".." in it? I think this path is wrong-headed.

>Perhaps clarity is simply obtained by noting that whenever
>Content-Base and Content-Location are found to have equal predence,
>the tie should be broken by giving precedence to Content-Location.
>
>This eliminates all the concern about explaining about header sets, et
>al.
>
>It also is independent of how the tie was discovered, whether found in
>the local MIME part, or by searching outward for scope.
>
>This looks very nice and tidy to me;-)...\Stef

Except again, we can all think of common practice where Content-Location is
really quite different from what the document expects for base resolution.

I think this demonstrates, in part, why there was so much worry in the WG
about allowing recursion of these things: Base can be specified, but if
it's not specified, it's taken from the location, and if that's not
specified you take it from the base of the parent. Which, BTW, brings up an
interesting question: Let's say I have the following:

Content-Type: multipart/related
Content-Base: foo://bar/biff/

    Content-Type: multipart/mixed
    Content-Location: blah://blee/blue.bar

        Content-Type: text/html

What is the base for the text/html, which has neither Content-Location nor
Content-Base? Is it <blah://blee/> (the base we use for its parent since it
has not Content-Base) or is it <foo://bar/biff/> (the specific base of its
parent's parent)?

I'm not saying these questions can't be answered, but it's certainly not
clear from any of the current documents. Allowing recursion just makes the
rules complicated and increases the chances for broken implementations.
Personally, I don't want to have to go through the same garbage I'm now
going through with HTML to implement workarounds for different bugs for
each implementation of this thing.

I won't object to recursion being allowed, but that definition better be
*really* tight. None of the current options impress me yet.

pr

--
Pete Resnick <mailto:[e-mail]>
QUALCOMM Incorporated
Work: [phone] or [phone] / Fax: [phone]