RE: Recursive look up of base in outer headers

"Andy Jacobs (Exchange)" <andyj@exchange.microsoft.com> Thu, 04 September 1997 17:33 UTC

Received: from cnri by ietf.org id aa13263; 4 Sep 97 13:33 EDT
Received: from services.bunyip.com (services.Bunyip.Com [192.77.55.2]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA02874; Thu, 4 Sep 1997 13:36:25 -0400 (EDT)
Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id NAA28266 for uri-out; Thu, 4 Sep 1997 13:16:09 -0400 (EDT)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id NAA28259 for <uri@services.bunyip.com>; Thu, 4 Sep 1997 13:16:05 -0400 (EDT)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id NAA29511 for uri@services; Thu, 4 Sep 1997 13:13:01 -0400 (EDT)
Received: from doggate.exchange.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mocha.bunyip.com (8.8.5/8.8.5) with SMTP id NAA29508 for <uri@bunyip.com>; Thu, 4 Sep 1997 13:12:45 -0400 (EDT)
Received: by DOGGATE with Internet Mail Service (5.5.1664.3) id <R7R13MGP>; Thu, 4 Sep 1997 10:15:27 -0700
Message-ID: <2FBF98FC7852CF11912A000000000001050F6D8A@DINO>
From: "Andy Jacobs (Exchange)" <andyj@exchange.microsoft.com>
To: 'Pete Resnick' <presnick@qualcomm.com>, mhtml@segate.sunet.se
Cc: uri@bunyip.com
Subject: RE: Recursive look up of base in outer headers
Date: Thu, 4 Sep 1997 10:15:23 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1664.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-uri@bunyip.com
Precedence: bulk

>>}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.

> 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.

An MHTML reader must be able to do this anyway, when resolving links to
other body parts.  If the referenced body part has both a Base and a
relative Location, they must be combined, taking into account "..", etc.
My suggestion was to be more consistent in always interpreting the Base
and Location as pairs.  Otherwise an inexperienced MHTML writer may want
to use a Base header for one purpose (to modify Location or to serve as
a base for embedded relative URL's) and not mean to have it used for the
other purpose.

Since I'm new to the standards process, I don't know whether this should
be a concern of the spec, and thus this might be a moot argument.
----
 - Andy Jacobs
   andyj@microsoft.com