3 Jun 1993 18:15
Re: MIME-Version is *not* useless
Steve Dorner <sdorner <at> qualcomm.com>
1993-06-03 16:15:13 GMT
1993-06-03 16:15:13 GMT
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.