Re: Minutes of the SMTP meeting in St. Louis

[Mark Crispin <MRC@xxxxxxxxxxxxxxxxxx>]

In <>, kankkune@cs.helsinki.fi writes:
>> 7-bit MTA's will never go away.
>And now it seems it isn't allowed to go away (no possibility to
>gradually change to mostly 8 bits).

You cannot legislate something that was previously conforming and generally
accepted into non-existance.  The last time this was tried was the NCP to TCP
transition in 1983.  DCA, the then owner of "the net", forced the transition
by modifying the packet switches on ARPANET to refuse to carry NCP traffic.
This involved great pain and *years* of effort to restore the former level of
service even though the total number of machines affected was fewer than what
exists on most college campuses today -- under 100.  Several systems left the
network permanently.

Other than this single exception, which required a military management body to
have enough power to carry it out, the only things that have been successfully
legislated into non-existance are those which were previously conforming but
*not* generally accepted.

In the case of 7-bit mail, there are important non-IP paths for mail which are
hopelessly 7-bits.  We have people interchanging email through X.29 PADs where
setting of the PAD parameters is administratively prohibited (personal horror
stories of X.29 pain and woe available at the cost of a beer).

Look at it this way.  Europe would be much better off if it had a single
national language.  We in the US communicate between states (and most Canadian
provinces) much easier than Europeans communicate between countries, including
states which are much larger than any European country excepting the USSR.  If
Europe adopted English, there would be no need for 8-bits at all.  But, Europe
will never adopt a single continental language, and certainly not English, and
no amount of wishing will make it happen.  It is the same thing with the 8-bit
MTA issue.

>It just seems a bit silly that the whole community needs to pay the
>complexity until the death of TCP/IP for those 7-bit sites.

According to the ISO partisans, the death of TCP/IP is only a couple of years
away.  It will take longer than that to change the SMTP infrastructure, much
less the entire small-i internet infrastructure, to be 8-bits.

Even if this is not the case, a migration to 8-bit MTA's is still a major
effort with only a minor gain.

Let me reiterate: 8-bit MTA's are not necessary for 8-bit email.  8-bit MTA's
are not sufficient for 8-bit email until/unless the day comes when the
transition is complete.  I feel that you (and a certain vendor) have greatly
underestimated the cost and time required to undertake this transition.

Solving 8-bits within the framework of RFC-822 is necessary until such time as
8-bit MTA's are the only ones which exist (which I do not believe will happen
in this century).  Solving 8-bits within the framework of RFC-822 is also
sufficient.  Furthermore, solving 8-bits within the framework of RFC-822
eliminates the need for an 7->8 bit transition and all the complexity of
conversion involved.

Isn't it true that you really don't care if one of your national characters is
sent on the wire as a single octet or three octets, as long as what you get on
your screen (and possibly also in your mail file) is a single octet
representing that character?

So, the true justification for 8-bit MTA's boils down to two arguments:
 (1) ease of implementation for some people, at the cost of complexity of
     implementation for other people including people who have no interest
     at all in 8-bit email.
 (2) a 12.5% data path efficiency, at the cost of inefficiency of having to
     debug all the extra level of 8/7 converters needed whenever the mail hits
     a 7-bit MTA (not to mention the inefficiency at having two different ways
     to encode the same 8-bit data -- 822-level and MTA level).
Neither of these arguments justify the cost.

>Many people
>already have 8-bit capable environment, but no, we must get a multimedia
>mail package to encode and decode messages just to write our own
>language...

No, you do not need multimedia mail.  You merely need typed mail.  It just so
happens that in North America we have no great need for 8-bit mail, but we
have a big need for a multimedia mail standard.  A standard multimedia mail
that is predicated on implementing typed mail would be a strong motivator for
North Americans to implement typed mail.

However, you wouldn't need to wait for us at all.  It is totally unimportant
to you whether or not North Americans do anything.  You can send typed mail
through North America and know that it will get to its destination in the
proper form, as long as the final recipient knows what to do with it.  That is
the one big difference from the present situation.  You cannot interoperate
with North America.  If your 8-bit mail hits our continent, it get trashed.

We are proposing a solution to this problem that is realistic if inelegant.
It is a solution where YOU, the people who care about the problem, can act to
deal with it.  You do NOT have to depend upon the (in)action of someone who
does not care about the problem.

The so-called "wretched solution" had this feature too, but it is in fact
harder to do and requires twice as much work because there are two levels of
encoding.

You can implement typed mail without ever implementing multimedia mail (the
Multipart type).  You can implement just the typing needed to send 8-bit
email, but with only a tiny bit more work you can send binary data as well.
With a bit more work on top of that you can play the multimedia mail game --
if you want to.  If you don't want to, none of the stuff about "cookies" etc.
applies to you.

>I just was stunned that the 8-bit solution was rejected
>based on such an invented "worst case", where I didn't even find any
>problem. I wasn't there, so I don't know all the arguments presented,
>but I hope there were some real problems found out, too.

It came out in the discussion that there are 7-bit UA's on UNIX (yes, UNIX).
Some of these 7-bit UA's crash with 8-bit mail.  Many of us have dozens of
different sendmail (and other) implementations to cope with on various
hardware platforms.  Often source files which compile on one platform will not
compile on another.  Often we have to individually maintain different
sendmail.cf files, all equivalent but with some subtle difference due to
individual sendmail implementation quirks.  And this is within the UNIX world.

Then there's all the non-UNIX systems out there.  Yes, even a few PDP-10's
(believe it or not, they're more likely to switch to handle 8-bit support than
a lot of UNIX boxes are).

For many heterogeneous platform organizations, this is a huge project.  Most
of the sites simply lack the manpower to throw at a "solution" that is neither
sufficient nor necessary to solve the problem.

-- Mark --