With the exception of modifying the sentence structure of item 1 (below)
for improved readability, I very much agree with Steve's suggestion!
Jim
As I am a fairly passionate advocate of the use of version
numbering schemes in furtherance of managed compatibility in the
face of protocol evolution, allow me to say a few words in
defense of the MIME-Version: header.
Explicit version numbers are a Good Thing. Far too often,
software packages or protocols become obsolete because they
cannot be modified without breaking backwards compatibility, or
interoperate poorly because version incompatibilities cannot be
detected in a deterministic way.
Even if the MIME-Version: header's sole purpose were to
differentiate MIME from pre-MIME or non-MIME mail, using it for
that purpose would be preferable to using heuristics based the
syntax of the Content-Type: header, etc.
An even better reason for having a MIME-Version: header, however,
is to allow for controlled evolution and growth. As stable,
complete, and open-ended as MIME may appear today, eventually a
need for new features and major modifications will arise, and
some of these will not be compatible with current
implementations. An eventual message composed using those new
features will have a much better chance of *not* being
mis-handled by one of today's MIME implementations if it is
tagged with something like MIME-Version: 2.0 .
With this possibility in mind, those current implementations
which have been castigated for refusing to process messages
having MIME-Versions of other than 1.0 are not too far off the
mark.
The policy with respect to MIME-Versions should be stated along
the lines of:
Messages which are compatible with the mechanisms
described in this RFC, and which can be displayed
meaningfully by mailreaders meeting this RFC's minimal
conformance standards, will bear the header
MIME-Version: 1.0
If future revisions of this RFC introduce mechanisms not
backwards-compatible with current mechanisms, messages
using those mechanisms will be required to be tagged with
a MIME-Version greater than 1.0 . (To assure maximal
interoperability, any revisions to this RFC will
encourage messages not using the new mechanisms to
continue to be tagged with MIME-Version: 1.0 .)
Implementations are encouraged to treat the MIME-Version:
header as follows:
1. Received messages without a MIME-Version: header
should be treated in a fallback mode, either as
if tagged Content-Type: text/plain; charset=US-ASCII,
or perhaps (with the aid of application-specific
heuristics) as some other tagged or structured,
non-MIME message type.
2. Received messages of MIME-Version: 1.0 should be
treated as described in this RFC, to the best of
the application's ability.
3. Received messages having a MIME-Version: header
specifying a version of other than 1.0 should
behave in one of the following two ways:
a. Offer to display the raw text of the
message, without interpreting the
Content-Type or any other MIME headers,
along with a warning message indicating
that MIME semantics are not being
observed due to version number mismatch.
The text thus displayed, though
suboptimal, will be essentially that
which a user without a MIME-aware
mailreader would see (and therefore as
useful as it can be, given that MIME
semantics cannot be observed).
b. With explicit user confirmation, and
accompanied by suitable warning messages,
display the message in accordance with
this RFC's specifications. Obviously,
the success of this strategy cannot be
predicted, as the nature of any eventual
backwards-incompatible MIME revisions is
not known.
For some reason, version numbering schemes are rarely used, and
when they are used, are rarely specified and implemented as well
as they could be. (Since the need for a version number is not
usually recognized until version 2 exists, version 1
implementations and data streams usually don't incorporate
explicit version numbers, so version 1 implementations are never
able to cope gracefully with version 2 data streams.) I was
pleasantly surprised, upon first reading RFC1341, to discover
that MIME is specifying a version number field from the
beginning. MIME-Version: is not broken, and still has the
potential to be useful. There is no good reason to discard it,
or to deprecate its use.
Steve Summit
scs(_at_)adam(_dot_)mit(_dot_)edu