Re: Recursive look up of base in outer headers

Klaus Weide <kweide@tezcat.com> Tue, 02 September 1997 22:58 UTC

Received: from cnri by ietf.org id aa25037; 2 Sep 97 18:58 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 TAA25727; Tue, 2 Sep 1997 19:01:25 -0400 (EDT)
Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id SAA01444 for uri-out; Tue, 2 Sep 1997 18:47:49 -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 SAA01439 for <uri@services.bunyip.com>; Tue, 2 Sep 1997 18:47:44 -0400 (EDT)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id SAA20458 for uri@services; Tue, 2 Sep 1997 18:45:23 -0400 (EDT)
Received: from xochi.tezcat.com (xochi.tezcat.com [204.128.247.12]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id SAA20455 for <uri@Bunyip.Com>; Tue, 2 Sep 1997 18:45:16 -0400 (EDT)
Received: from localhost (kweide@localhost) by xochi.tezcat.com (8.8.5/8.8.5/tezcat-96091001) with SMTP id RAA16932; Tue, 2 Sep 1997 17:47:25 -0500 (CDT)
Date: Tue, 02 Sep 1997 17:47:23 -0500
From: Klaus Weide <kweide@tezcat.com>
To: Al Gilman <asgilman@access.digex.net>
cc: mhtml@segate.sunet.se, uri@bunyip.com
Subject: Re: Recursive look up of base in outer headers
In-Reply-To: <199709022100.RAA03064@access4.digex.net>
Message-ID: <Pine.SUN.3.95.970902174216.18545F-100000@xochi.tezcat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-uri@bunyip.com
Precedence: bulk

On Tue, 2 Sep 1997, Al Gilman wrote:

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

Your suspicion is based on speculation, which could have been avoided by
"doing your homework"...

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

Since the first paragraph is wrong in what it says about HTTP, there is no
basis for this suggestion.

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

I agree with this, though.  But I don't think anybody disagrees.

   Klaus