ietf-822
[Top] [All Lists]

Re: MIME-Version is *not* useless

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