Re: Recursive look up of base in outer headers

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

....Roy

Received on Wednesday, 3 September 1997 02:44:42 UTC