Re: Recursive look up of base in outer headers

Al Gilman <asgilman@access.digex.net> Tue, 02 September 1997 21:14 UTC

Received: from cnri by ietf.org id aa23400; 2 Sep 97 17:14 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 RAA25456; Tue, 2 Sep 1997 17:17:26 -0400 (EDT)
Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id RAA29070 for uri-out; Tue, 2 Sep 1997 17:00:30 -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 RAA29064 for <uri@services.bunyip.com>; Tue, 2 Sep 1997 17:00:27 -0400 (EDT)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id QAA19871 for uri@services; Tue, 2 Sep 1997 16:58:07 -0400 (EDT)
Received: from access4.digex.net (access4.digex.net [205.197.245.195]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id QAA19868 for <uri@Bunyip.Com>; Tue, 2 Sep 1997 16:58:04 -0400 (EDT)
Received: (from asgilman@localhost) by access4.digex.net (8.8.4/8.8.4) id RAA03064; Tue, 2 Sep 1997 17:00:20 -0400 (EDT)
From: Al Gilman <asgilman@access.digex.net>
Message-Id: <199709022100.RAA03064@access4.digex.net>
Subject: Re: Recursive look up of base in outer headers
To: Jacob Palme <jpalme@dsv.su.se>
Date: Tue, 2 Sep 1997 17:00:20 -0400 (EDT)
Cc: mhtml@segate.sunet.se, uri@bunyip.com
In-Reply-To: <v03110700b031e7c5aae8@[130.237.158.12]> from Jacob Palme at "Sep 2, 97 05:58:53 pm"
X-Mailer: ELM [version 2.4ME+ PL15 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-uri@bunyip.com
Precedence: bulk

to follow up on what Jacob Palme said:

> 
> 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. Is there
> any problem with this? Clearly, the standard must specify which
> has precedence, good standard should not leave things like
> this undefined. "undefined" in my opinion is an ugly word
> in standards documents.
> 

Some more loose talk from this end -- I haven't done the homework
implied:

I suspect that HTTP is willing to trust that header fields are
received in the order sent, and give precedence to the textually
last header field within a [single message header, or by
extension the headers of a single MIME part].  Since in the email
context you may not wish to trust that header fields are received
in the order that they were sent, you may have a good reason not
use that as the basis for resolving conflicts.

Personally, I see some virtue to a policy which would make the
presence of both a Content-Base and Content-Location header field
within the same header block an error [leaving BASE undefined] if
they do not agree as to the implied BASE.  But I do see the
choice whether to fix this quietly, fix it with a warning, or not
fix it as a judgement call without an iron-clad case for any one
choice.

Particularly, if the same Content-Base + Content-Location value
pair are at risk of being interpreted one way when transmitted
in MIME and another way when transmitted via HTTP I see this as
a likely source of trouble and too arcane for prime time.  

--
Al Gilman