Date: Fri, 3 May 91 18:51:15 -0400
To: ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu
Subject: Protecting the installed base
From: ljm(_at_)ftp(_dot_)com (leo j mclaughlin iii)
[...]
Furthermore, (though the merits of this decision are another debate) this
group has already decided that MTAs which are not strictly 821 compliant
in their use of 7-bit ASCII (i.e. they use 8-bits) are verboten and to be
discouraged. If an MTA is incapable of passing 7-bit ASCII because an
implementor was lasy and didn't do proper mapping in and out of their EBCDIC
enclave than that MTA needs to be fixed.
That's odd. I recall that at St. Louis one of the questions put to the group
was something like "should this new message format be usable by non-Internet
mail systems?" and the response was overwhelmingly positive.
Finally, no matter what we say, users sitting behind such a broken MTA have to
pay a hefty price -- their BASE64 encoded data will for the most part only be
understood by users with new-style MTAs.
Even after this standard is adopted, I would expect that users will continue
to use uuencode, Binhex, btoa, or whatever, for a long time, as a means of
transporting binary files, since all of these have a larger installed base
than BASE64. Nothing in RFC XXXX prevents us from doing this. Furthermore, I
don't see that this causes a problem, as long as uuencoded files pass through
8->7 bit gateways unchanged.
On the other hand, if I'm sending a multipart message with ISO 10646 text and
sound and fax and other fancy stuff, then I am doing so with the expectation
that my recipients have a newfangled UA that can support these features. It
seems fairly likely that such a UA will also support whatever the encodings
defined by RFC XXXX. If I try to send out a complex multipart mail message
right now, the number of users who could read it if it were uuencoded is not
much greater than the number of those who could read it if it were encoded in
BASE64. Given the number of other changes to UAs that are required to support
RFC XXXX, the incremental effort to support BASE64 over uuencode seems pretty
small. I therefore don't see any advantage in using uuencode when sending
complex multipart messages, as opposed to sending an encapsulated file.
I really don't expect that many users are going to be willing to decode
complex messages "by hand" on a routine basis, even if they have the basic
tools to do so. What's more, I don't expect that in general the tools to do
so are widely available. (What good is a uuencoded fax message if I don't
have any way to display it?) Of course, if I have a RFC XXXX-compliant UA
then this capability will be supplied with it.
The trade-off seems to be something like this: If uuencode is the preferred
content-encoding, then the RFC XXXX standard will be accepted more quickly,
since some RFC XXXX messages could be decoded "by hand" using existing tools.
(IF the recipient also had the tools to display fax, play audio, etc., once
the message were decoded.) On the other hand, we have experience that
uuencoded messages don't survive some kinds of email transport. As long as we
want to talk to people with these kinds of transport, we lose interoperability
if we go with uuencode.
So we have to decide whether it is more important to use a de facto standard
now or to promote a standard that will work for everyone in the long term.
Keith