sdorner(_at_)qualcomm(_dot_)com (Steve Dorner) writes:
As for ignoring the value, that's another story. That's certainly my plan,
until some reason to do otherwise comes along.
If you ignore the value, you are contradicting a recommendation in
section 3 of the April Internet Draft. This is a problem which I
think should be addressed. The new MIME spec should instead be
de-empasizing the header, recommending that software ignore its value.
As for whether or not a message is or is not "MIME", why should anyone
care? The term has no definiton or practical meaning.
In practical terms, what one usually needs to know is whether or not
RFC 1341 or its successors specify an interpretation of the message.
That is true (to varying degrees) for messages with a syntactically
valid Content-Type: header and for messages without a Content-Type:
header. It is not in general true for messages with RFC 1049
Content-Type's.
One may also want to know whether or not one can infer that a message
obeys some constraint of RFC 1341, for example that it is 7-bit clean
in the absence of a Content-Transfer-Encoding. One could use either
Content-* or MIME-Version for this purpose, using MIME-Version is
admittedly one step easier than using Content-*. As this inference is
at best a heuristic (it is unlikely, but not invalid for a
non-RFC-1341 message to have a MIME-Version: 1.0) it is not by itself
sufficient to keep MIME-Version.
(Existing software is, on the other hand, sufficient reason to keep
the MIME-Version requirement for at least one revision.)