Re: MIME-Version is *not* useless

At 11:03 AM 6/3/93 -0400, Steve Summit wrote:

>             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:

Specifying "other than 1.0" is too restrictive, and is part of the problem
with the MIME-Version header.  I can imagine messages that are completely
compatible with 1.0 implementations, but that (eg) a 1.1 implementation
might be able to deal with "more optimally".

For example, imagine we suddenly discover that there is some mail gateway
that eats "H" characters.  So in MIME 1.1, we change the quoted-printable
encoding to require that "H" be encoded.  A mail gateway that sees a MIME
1.0 message might want to redo the quoted-printable in it to encode all
H's.  A mail gateway that sees a MIME 1.1 message would know it didn't need
to take this step.

Here, the 1.1 message is still entirely compatible with a 1.0
implementation, but it helps to know it's 1.1.

So I would suggest that the two parts of the version number be treated
separately.  A change in the major number would indicate an incompatibility
with older versions.  A change in the minor number would indicate some kind
of "value-added" thing that is not necessarily incompatible with 1.0
implementations.  So, to a 1.0 implementation, "2.0" would be trouble but
"1.1" would be No Big Deal.  Or something like that.

Like a wise man  said:

>An even better reason for having a MIME-Version: header, however,
>is to allow for controlled evolution and growth.

I have two problems with the following statement:

>                     b. With explicit user confirmation, and
>                        accompanied by suitable warning messages,
>                        display the message in accordance with
>                        this RFC's specifications.

1. User interfaces should not be prescribed by Internet standards.  A
certain degree of this is inevitable, of course, but it should be minimized
whereever possible.

2. If you *are* going to legislate UI issues, it's a mistake to require
*explicit* user confirmation and warning messages.  This will be
intolerable in many environments.  A user is unlikely to get just one
MIME-Version: 2.0 message; he's likely to get great gobs of them, and
dealing with great gobs of warning messages and confirmations just won't
do.  Users should be allowed the choice of warning levels and actions, so
that these decisions can be made implicitly as well as explicitly.  If this
is what you meant to say, I think the language could be clearer.

--
Steve Dorner, Qualcomm Inc.
Oldthinkers unbellyfeel IngSoc.