Re: Recursive look up of base in outer headers

"Roy T. Fielding" <> Wed, 03 September 1997 06:54 UTC

Received: from cnri by id aa09259; 3 Sep 97 2:54 EDT
Received: from (services.Bunyip.Com []) by (8.8.5/8.7.3) with ESMTPid CAA27744; Wed, 3 Sep 1997 02:57:08 -0400 (EDT)
Received: (from daemon@localhost) by (8.8.5/8.8.5) id CAA08671 for uri-out; Wed, 3 Sep 1997 02:44:42 -0400 (EDT)
Received: from (mocha.Bunyip.Com []) by (8.8.5/8.8.5) with ESMTP id CAA08666 for <>; Wed, 3 Sep 1997 02:44:39 -0400 (EDT)
Received: (from daemon@localhost) by (8.8.5/8.8.5) id CAA22013 for uri@services; Wed, 3 Sep 1997 02:42:12 -0400 (EDT)
Received: from ( []) by (8.8.5/8.8.5) with SMTP id CAA22010 for <>; Wed, 3 Sep 1997 02:42:09 -0400 (EDT)
Received: from by id aa06037; 2 Sep 97 23:43 PDT
Subject: Re: Recursive look up of base in outer headers
In-reply-to: Your message of "Tue, 02 Sep 1997 22:48:43 PDT." <>
Date: Tue, 02 Sep 1997 23:37:41 -0700
From: "Roy T. Fielding" <>
Message-ID: <>
Precedence: bulk

>Thus, all assumptions that might be made about the order of headers
>being meaningful is totaly false in the EMail World.  This is a fact
>of life in the massive Internet EMail Installed Base, and wishing this
>was not so is quite pointless.  Lets not bother with such wishes.

Yep.  The same is true of HTTP, at least to the extent that header
fields with different names could be rearranged in transit.  This is
necessary to support implementations where the header fields are
stored for caching/proxying as a hash table.

>So, I think it is important for MHTML to specify that no meaning is to
>ever be implied by the order of apperance in received MIME HEADERS
>(i.e., Content-*) in any MIME HEADER SET (i.e., that set of MIME
>HEADERS that are found together without separation by a "DOUBLE
>NEWLINE" (CRLFCRLF) or "A BLANK LINE".  This definition comes out of
>RFC822 and the basic MIME RFCs.
>Thus we (MHTML) must precisely define which of Content-Location or
>Content-Base has precedence when they ar both found together in a
>single MIME HEADER SET.  It must always be either Content-Base or
>Content-Location, and the implementors should know from our standard
>that when both are present, whcih one will govern, so as to avoid
>putting the recipient into an impossible ambiguity.

Exactly.  Right now all the RFCs say Content-Base has precedence over
Content-Location when they are both found together in a single MIME
HEADER SET, though nowhere near as concisely and lacking the formality
of a definition for MIME HEADER SET.  Such a definition is an excellent