The situation with MIME is, to put it mildly, perceived of as a disaster
and a complete refutation of the hypothesis that MIME can operate
transparently, with no change to MTAs or gateways.
Whoa. There is no such hypothesis that I'm aware of. Moreover, anyone who makes
such claims is in serious need of a reality check.
A quick example is all that's needed to show how absurd such a claim would be.
Just to be different, let's select the example of a gateway between RFC822 and
Novell MHS mail. The most casual inspection shows that such a gateway cannot
adequately cope with MIME without some modification. Sure, the gateway can take
a MIME message, treat it as pure RFC822, and convert it into SMF. Once there
the Novell MHS world won't have the slightest clue what to do with the MIME
material that's embedded in the message. In addition, since the gateway was
expecting US-ASCII in conformance with RFC822, the character set is also likely
to be messed up. Moreover, there's no expectation that the message will be
converted back into valid MIME if it is forwarded back out into the RFC822
world -- at a minimum, the necessary MIME headers will almost certainly not be
present.
Now let's consider the issue of MTA transparency. And remember, we're talking
about strict MTAs here -- as I've just illustrated, once you enter the world of
gateways all bets are off.
An RFC821 MTA is an entity that transfers valid RFC822 messages around,
subjecting the contents of those messages to the very very limited set of
tranformatations permitted by the standards. Specifically, about all an MTA is
supposed to do is add headers to the message, and the list of possible headers
that can be added is very short.
MIME itself defines a canonical message format plus a set of representation
formats. The set of all MIME messages represented in 7 bit form can easily be
shown to be a strict and proper subset of the set of all RFC822 messages.
So, what we have here is that MIME, if properly used, always generates messages
that unconditionally fall within the set of messages a conformant MTA is
required to be able to transport. Conclusion: Any RFC821 MTA that cannot carry
such a message is either incompliant with standards or misclassified and hence
not an MTA at all. And this is no hypothesis; it is the actual result of
careful design.
But what about non-RFC821 MTAs, you ask? Theoretically, these fall into two
groups -- those that transfer RFC822 using something other than SMTP and those
that transfer messages in another format. Now, if the transport carries RFC822
it is bound by RFC822 rules as to what can be added to the message during
transport as well as what it must be able to accomodate. Such transports
therefore can handle MIME transparently.
The second group of transports are those that carry some other message format.
Once you think about it you'll quickly see that they're just not impacted by
MIME. The reason for this is quite simple: an MTA that transport something
other than RFC822 can come into contact with MIME in one of two ways: (1)
It receives it directly, in which case it isn't an MTA at all; it is a gateway,
or (2) It receives it indirectly, in which case by definition it must have
passed through a gateway somewhere.
So the result is that half of this supposed hypothesis is simply preposterous
and the second half is either a fact or equally preposterous, depending on what
sort of MTA you're talking about.
There is some feeling on the BITNET side of things (articulated so far mostly
in the mode of hotheads and flamers) that IETF has been totally irresponsible
to turn this thing loose with the claim that it has no transport implications
and that the problems it has caused already are grounds for scrapping MIME and
starting over (I'm just reporting here, not expressing agreement with feelings
nearly that strong).
I'm sorry, but the claim has to be substantiated prior to discussing the
consequences.
The BITNET issue boils down to one question that's really easy to state: What's
the message format that BITNET uses? If the message format is RFC822 (and hence
the use of EBCDIC is transformation of convenience that occurs at, say, the
transport layer) then the BITNET-Internet gateways are really not gateways at
all; they are just MTAs. MIME should work transparently across all of BITNET is
this is the case. But if the message format isn't RFC822 then there was never
any sort of expectation that no modifications of the gateways would be needed.
Having said this, honesty compells me to point out that I simply don't know
which one of these views is correct; as far as I know there are no officially
sanctioned documents to tell me what it is that BITNET actually uses.
I am aware of three proposed realistic and comprehensive solutions to
emerge so far:
(i) changing the base transport of that network from EBCDIC to ASCII
(ii) changing the gateways to recognize MIME messages and sending
them, and them only, specially-encoded, without character translation.
(iii) Recognizing MIME messages at the gateways and bouncing some or
all of them as undeliverable to BITNET hosts.
While these options may be feasible (!), they are not consistent with
statements about being transport-transparent, nor about ones about
avoiding disruption to the installed base.
The problem here is that solutions are being discussed before the nature of the
problem is understood. Without coming to grips with our present lack of
understanding of what it is that BITNET carries around it simply isn't possible
to make such choices intelligently.
This is why I strongly supported the development of consistent character set
standards for BITNET at the least CRENTAC meeting I attended. Such a standard
is a necessary first step in coming to grips with the problem. There are
several additional steps that have to be taken as well; the resulting
character set definition has to be bound to a message format and transport
protocol.
BITNET is in the envious position of being able to define these things after
the fact with what amounts to 20:20 foresight. That is, it is now possible to
make choices which subsequently will ease the transition to MIME considerably;
at least path leads can readily be imagined that would lead to essentially no
perturbation of the installed base whatsoever. The only depressing thing about
all this is that political agendas could quite result in a suboptimal and
possibly disasterous choice being made.
But maybe some of
those gateways have now been updated to take MIME into account. Or
perhaps the UAs in those environments have been updated to take this
issue into account. Does anyone know of such changes?)
While I'm aware of some attempts to locally minimize the impact of
these problems (especially on the ASCII machines on BITNET), the
official gateways have not been changed, nor have any of the widely-
available UAs or mail-based applications software on the EBCDIC
platforms.
And this is an outcome I can live with; the result is that the gateways are
MTAs as far as MIME is concerned and transport independence is immediately
achieved. The big disadvantage is that the EBCDIC platforms now have no way to
take advantage of MIME.
Because a host may receive mail passed through any of several
different gateways, having UAs compensate ("take the issue into
account") is not practical unless either all gateways behave the same
way--which might include extending or modifying MIME to canonically
document what was done so that UAs could act accordingly.
It is well understood that a partial update of all the gateways would be
a total disaster. Whatever solution is adopted must be universal.
But updating all the gateways at once is a problem whose difficulty is easy to
overstate. There are what, three? four? implementations. And this can be done
in three (or more) stages -- first deploy the necessary software, enable the
BITNET-->Internet actions so experimentation can occur, and finally enable the
whole thing everywhere. The critical problems are deciding what to do and
getting the implementations changed. (I cannot speak for the other
implementors, but I've been aware of the need to do this since before the first
MIME draft was posted to the ietf-smtp list (there was no ietf-822 list then)
and I'm been ready to make the necessary changes to PMDF since that time.)
Because the gateways are not centrally administered (and because the
description of the collection of administratively separate, but
protocol-sharing, networks involved as "Cooperating" is a statement of
hope and intent but occasionally not fact) plans that would require
flag-day switchover of either gateways or UAs are non-starters.
I cannot speak to the political agenda, but I agree that flag-day switchover
isn't feasible. However, there is no need for such a flag-day; migratory
and staged approaches to solving the problem do exist.
Many years of effort have gone into making the BITNET mail
environment transparently interoperable with the Internet one in this
many-gateway and dual-homed-host environment, even if those efforts have
not always been completely successful. One of the traditional tests for
the level of interoperability expected was that one should be able to
perform a "remail" or "forward" operation without worrying about which
of the parties involved (originator, first recipient/ forwarder, final
recipient) were on which side of the gateways or, of course, which
gateways were in use. Prior to MIME, this worked. At this point, we
have EBCDIC floating around BITNET labelled as ASCII and some ASCII
floating around there and labelled as ASCII (mostly on individual
hosts). It is probably only a matter of time before we have EBCDIC on
the Internet labelled ASCII and multipart MIME messages floating around
that have all parts labelled as ASCII but that are actually mixed.
Fairly unattractive situation, really.
I think this overstates the case. The technical issues I believe to be
tractable and I've no evidence to the contrary; the fact that they admit
several solutions whose consequences can readily be determined is a luxury we
don't often have. If there's anything unattractive or intractable it is on the
political side.
Ned