Re: A proposal

[Erik Naggum <erik@xxxxxxxxxxxx>]

> This proposal seems quite coherent and reasonable if we accept the
> premise that we want to modify SMTP.

The first part of my proposal introduces an extremely quiet change
to SMTP -- namely, not protocol change, only a change in the inter-
pretation of the third token, if any, in the 220 greeting line.  I
thought it would be wise to include an argument for a change to SMTP
protocol-wise and shoot it down just to show that this wouldn't be
needed.  I hope readers of my message noticed that I didn't end up
favoring the 228 reply code.

The reasons I want to add this, is that the 7-bit restriction in SMTP
is overly conservative and is being outdated by current hardware and
software.  I don't intend to dispense with the 7-bit restriction, only
to let two consenting partners engage in 8-bit data transfer without
interference from others.

In other words, "change SMTP" has had its meaning extended into the
realm of "quite change" instead of "dramatic incompatibility problem".
I suggest we not treat all changes to SMTP as just "changes to SMTP",
but try to make some qualitative estimate of deployment cost and benefits.

> It is clear from the discussions thus far -- as argued by Dave
> Crocker, Einar Stefferud, myself, and many others -- that no SMTP
> changes are really necessary because we can encode 8 bit multipart data
> in a form that can be passed through SMTP as it currently exists.  Such
> a solution is a bit less efficient in its use of bandwidth, but requires
> no changes to existing MTA's and relays.  

I asked, quite politely, I thought, that we separate the issues of 8 bits
and multiple body parts.  I would like to be able to send ISO 8859-1 mail
to people on the same system, for instance.  Currently, this debate gives
the indication that we can't do that.  There may be people out there who
think that Europeans will get new and fancy software to handle this magic
conversion into 7-bit-ness from an 8-bit mail much faster than their MTAs
will change.  I don't think so at all.  I think Europeans will continue
to use their "ISO 646 with variants" if they don't get 8-bit data paths,
or at least 8-bit transparent data paths, which means changing MTAs anyhow.
Stuffing all kinds of kluges into the UA is not going to solve this, for
several reasons:  (1) They aren't really made for Internet use, only
poorly adapted to RFC 822 (mail, mailx, elm).  (2) They're frozen in terms
of installed base much more than MTAs are.  (3) Getting UAs to agree on
a standard representation of ordinary 8-bit text is much harder than to
get one MTA on each system do it.

For multi-part, multi-media message interchange, I agree that we can
probably get it done without changing SMTP, but only because you have
to have a new and fancy UA to figure out what the message is all about.
That is simply not the case for Joe's Average User Agent and his mail
needs.  The overhead in the new message formats makes it sensible to
go for 7-bit as the lingua franca for message interchange.  For mail,
the conversion is perceived by the user to be much more troublesome.
("Mail" and "message" as defined by John Klensin.)

Again, between consenting SMTP partners, we should allow 8-bit data paths,
and support for ISO 8859-1 by a simple change in the way the SMTP server
waves its hand in greeting you.  Old clients will be oblivious to this,
but those in the new clique will know what to do.

[Erik], who thinks his idea is getting better and better.