At the risk of getting caught with a protocol-lawyer hat on, I'd suggest
that this discussion is a waste of time as well as a little too late.
(1) We know that there are implementations out there that predate MIME,
interpret Content-type differently, and that we decided, explicitly, to
provide something they could use as a switching mechanism, rather than
breaking them. They were perfectly well-behaved until RFC822 rules, and
it might even be worth noting that RFC1123 _standardized_ Content-type.
Maybe either that decision, or the mechanism chosen, were not ideal,
but, at this point in MIME's development, it would take proof of
brokenness in the spec to change either, not just a quibble about
utility.
(2) There are no protocol police. Still worse, there are no protocol
judges and protocol jails other than the hope that people who misbehave
long enough will eventually lose market share (there has been no
evidence of this in the email realm so far). As a result, over-close
reading of conformance assertions in protocol documents is typically a
waste of time. That is what the robustness doctrine is all about.
Providing MIME-version is conservative on the sending side because it
tells the recipient exactly what you are sending, with no need for
heuristics. And every recipient system gets to decide whether, in its
environment, it is more sensible to treat a message that arrives without
"MIME-version" but with Content- headers as MIME or non-MIME, presumably
by evaluating the implications of both options. And that is why the
document doesn't make a "you have to" rule about this, one way or the
other.
(3)
As I mentioned before, RFC 1341 does not permit MIME readers to ignore
Content-* headers in the absence of a MIME-Version: header. RFC 1341
defines a number of headers (Content-Type, etc) and a number of values
The rule you are inferring here can't be written, since the only thing
it governs is what a MIME-reader has to do under circumstances in which
its producer claims that it is a MIME-reader.
Regardless of what RFC1341[bis] says, if I were writing a proposal
or bid, and expected someone to sue me if I claimed MIME-compliance and
wasn't, I'd say "this critter is RFC1341-compliant in its processing of
incoming messages that conform to that standard". That is the strongest
comformance guarantee you would ever get, and, if you send a message
that doesn't contain MIME-version, you wouldn't have a leg to stand on.
Nowhere in
RFC 1341 is there an exception allowing an implementation to ignore a
Content-* header in the absence of a MIME-Version: header.
Such an exception would be so much noise, unless you intend to
prohibit software that claims MIME-compliance from interpreting plain,
ordinary, RFC822 messages. An RFC822-reader is free to ignore any
headers it doesn't understand, and to make the "don't understand"
decision either globally or on the basis of context.
This does not necessarily imply that the message is
not in MIME format--there will be other RFC's which will supersede RFC
1341.
True. But, unless we encounter evidence of a catastrophic problem,
"MIME" and "MIME format" are what RFC1341 and its successors say that
they are: there isn't some Platonic-ideal-MIME out there that we are
trying to approximate in the real world. In particular, (i) I'd expect
those RFCs to preserve the MIME-version requirement unless there is
evidence that it is harmful and (ii) if MIME-version isn't there, it
doesn't necessarily imply that the message is not in "green cheese"
format either. You really know nothing at that point other than
"RFC822" and, depending on how you received it, you may not be able to
guarantee that.
--john