Hello Greg,
A Draft Standard may still require additional
or more widespread field experience, since it is possible for
implementations based on Draft Standard specifications to
demonstrate unforeseen behavior when subjected to large-scale
use in production environments.
There is such a bug in RFC 1341, actually:
Default RFC 822 messages are typed by this protocol as plain
text in the US-ASCII character set, which can be explicitly
specified as "Content-type: text/plain; charset=us-ascii".
If no Content-Type is specified, either by error or by an
older user agent, this default is assumed.
There is a blatant contradiction in the logic behind MIME's design.
Base64 was carefully designed to be "transmissible" anywhere, even
through a succession of brain-dead EBCDIC gateways that "alter"
certain characters, especially the characters defined by ISO 646 as
being intended for "national graphic character allocation" (i.e.
things like backslash (\) that look different on certain people's
screens).
However, the header that identifies a Base64 message as such
(Content-Transfer-Encoding) is *not* designed to be "transmissible"
anywhere. Apparently, there is an enclave in the UK that only
transmits certain RFC 822 headers, and other headers are dropped. I
would guess this enclave is JANET, but I'm not sure.
Anyway, since it is clearly impossible for people in such an enclave
to send RFC 1341 conformant messages to "the Internet", since it is
just too impractical to alter the large number of gateways that
translate from that enclave to the Internet, MIME should be changed to
put the Content-Type, Content-Transfer-Encoding, etc headers in the
"body" itself, i.e. not in the "RFC 822 headers".
This problem is not limited to enclaves such as that described above,
incidentally. Certain mailing list servers also misbehave (but are a
fact of life). For further background and explanations of this whole
issue, see the Usenet newsgroup comp.mail.mime article that I have
included below.
There are several solutions that I think we should consider:
1. The way the "Andrew" implementation used to do it. (Nathaniel, would
you care to describe this?)
2. Harald Alvestrand's X.400-related proposal:
MIME-version: \d+.\d+\r\n
at the beginning of the "body". (Harald, could you explain the \d
etc?)
3. Alasdair Grant's proposal:
.)MIME
also at the beginning of the "body".
Here's that article I referred to above. (By the way, there's a
little mistake in it, namely, I should have said "a DIFFERENT version
of the same gateway program" instead of "a DIFFERENT instance of
..".)
Newsgroups: comp.mail.mime
From: erik(_at_)poel(_dot_)juice(_dot_)or(_dot_)jp (Erik M. van der Poel)
Subject: Re: Using MIME without extra mail headers
Message-ID: <C0vpq7(_dot_)Evv(_at_)poel(_dot_)juice(_dot_)or(_dot_)jp>
Date: Fri, 15 Jan 1993 04:56:30 GMT
If the domain isn't inherently capable of passing unrecognised RFC 822 style
headers through, then the gateways into and out of the domain should encode
and decode the information respectively in some form that the domain can pass
such as by performing the afforementioned gross hack.
It is difficult to predict what would happen if "they" took your
advice, but a conceivable scenario is as follows:
Some people in the domain (let's assume it's called JANET) decide to
take your approach, and change their MUAs in such a way that the
MIME-specific headers (Content-Type et al) actually appear at the top
of the message body itself (i.e. not in the "822" headers).
The same people have ready access to a couple of gateways between
JANET and the Internet, so they change those too, so that only RFC
1341 conformant messages are emitted from those gateways.
Now, suppose there's a mailing list server somewhere in JANET and some
of the people with the new MUAs send messages in the new format to the
server, only to find that it sends messages out to the Internet
through a DIFFERENT instance of the same gateway program to the
Internet, and they have no control over this program, in fact, the
administrator is very busy and just doesn't want to hear about these
changes they want him to make. (This part of the scenario is actually
quite realistic.)
So what happens is that these new types of messages actually spill out
of the domain, onto the Internet, and then some people in the Internet
still want to make use of those messages in a meaningful way, so they
hack their MIME implementations to understand the new format, and
Presto! we have witnessed the birth of a de facto standard.
(Please remember that most of this is speculation.)
Now, changing the topic a little...
The thing is, this problem is NOT limited to non-Internet "domains".
I have personally witnessed a mailing list server on the Internet
itself, that deletes Content-Type headers before forwarding the
messages to the list subscribers.
The fully anticipated reply to this is that such servers should be
fixed. And my reply to that is: You do it, I don't have the time to
argue with those people!
It may be that the same can be said about LISTSERV, which is actually
installed in many places and used quite a lot. I haven't tried
sending a MIME message to, say, the ISO10646 list yet, but perhaps it
would be a good idea to try it.
In fact, maybe the MIME designers should try to use their standard on
the Greater Internet before making assumptions...
-
--
Erik M. van der Poel
erik(_at_)poel(_dot_)juice(_dot_)or(_dot_)jp