At 1:08 PM 5/28/93 -0400, John Gardiner Myers wrote:
distinguish MIME messages from pre-MIME message by determining whether
the value of any Content-Type or Content-Transfer-Encoding header can
be parsed using the apropriate MIME BNF.
I disagree. If the header is required to be present, then it should be the
key for deciding whether or not the message is MIME. Syntactic analysis of
header fields to determine something already explicitly stated is
pointless.
Note also that MIME-compliant messages are NOT required to have
Content-Type headers, and that this has explicit meaning:
Content-Type: text/plain; charset=us-ascii
So requiring a syntactically valid Content-Type header to recognize a MIME
message either a) is a violation of the MIME spec or b) requires that the
absence of a Content-Type header is a syntactically correct Content-Type
header, in effect declaring all mail as MIME mail (except for messages that
have RFC 1049 Content-Type's, of course).
What's the difference between MIME mail "text/plain; charset=us-ascii" and
non-MIME mail? Practically speaking, very little; it's just a nit. But
since this entire argument is based on a nit with the MIME spec (that it
doesn't explicitly state that the MIME-Version header must be present for
the other headers to be considered according to spec), I don't feel too bad
about that.
As for ignoring the value, that's another story. That's certainly my plan,
until some reason to do otherwise comes along.
--
Steve Dorner, Qualcomm Inc.
Oldthinkers unbellyfeel IngSoc.