Re: Recursive look up of base in outer headers

Cutting to the "Chase Scene";-)...  
And avoiding the need for everyone to do a lot of homework.
This would be shorter if I were smarter.

One clear aspect of MIME, as it was designed to Tag and Bag
application Information Objects for transport via EMail, which is the
most hazzardous transport and most likely-to-damage-its-freight.  It
is widely recognized that many EMAIL GATEWAYS like to rearrange things
to suit somone other than the sender's concept of what is the right
order of RFC822 (and MIME) headers, etc.  

The basic problem is that they tend to take messages apart, and then
put them back together in other contexts, whcih may not allow the
original order to be maintained.  Or in handling, they just gets stuff
out of order.  So, in RFC822, order was delcared to not be meaningful.

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.

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.

It woudl be very helpful if other related standards for such as HTTP
would ageree with this principal so that all implementing parties will
always have been informed of the facts.

Perhaps we also need to somewhere carefully define what we mean by a
"MIME HAEDER SET".

Cheers...\Stef

>From Klaus Weide's message Tue, 2 Sep 1997 17:47:23 -0500 (CDT):
}
}On Tue, 2 Sep 1997, Al Gilman wrote:
}
[SNIP]...[SNIP]...[SNIP]...[SNIP]...[SNIP]...[SNIP]...[SNIP]...
}
}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

Received on Wednesday, 3 September 1997 01:59:07 UTC