[Top] [All Lists]

MIME-Version is *not* useless

1993-06-03 08:03:18
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

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

<Prev in Thread] Current Thread [Next in Thread>