[Top] [All Lists]

Re: MIME-Version is *not* useless

1993-06-03 09:16:19
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.

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