Message-Id: <199602290140.UAA15332@wilma.cs.utk.edu>
From: Keith Moore <moore@cs.utk.edu>
To: djb@koobera.math.uic.edu (D. J. Bernstein)
cc: drums@cs.utk.edu, moore@cs.utk.edu
Subject: Re: comments from a newcomer 
In-reply-to: Your message of "29 Feb 1996 00:41:04 GMT."
             <19960229004104.17097.qmail@koobera.math.uic.edu> 
Date: Wed, 28 Feb 1996 20:40:17 -0500
Sender: moore@cs.utk.edu

> > [[Note in draft: Keith and Ned suggest that we should invent a new
> > error code to be sent by the server when it shuts down the connection
> > because it has timed out waiting for a client command and that it
> > should be a 5yz code (since nothing temporary is happening).
> 
> Are you people actively _trying_ to cause reliability problems?
> 
> Imagine, for example, that a RCPT packet is delayed; the server times
> out; and the server sends 555 TIMEOUT. Would you say that ``nothing
> temporary is happening''?
> 
> In fact, since a typical SMTP client doesn't pay attention to incoming
> data until it's sent a command, it's hard to imagine how your proposed
> timeout code could ever _avoid_ incorrectly bouncing mail!

It's been so long since we (John and I) discussed the timeout code
that I don't remember why I thought that the reply-code should be 5xx.  
(would John or Ned like to refresh my memory?)
Looking at it now, it seems like a 4xx code would indeed be more 
appropriate -- the client would naturally interpret such a code
as "give up for now and try again later". 

The real point here, I think, was that a server should not simply
close a connection without sending some error code.

> > MUST NOT transmit messages with information in the high-order bit
> 
> Why not? If you're updating the SMTP spec, how about bringing it in line
> with reality by dropping the 7-bit restriction? Europeans transmit 8-bit
> messages all the time.
> 
> The current 7-bit restriction produces a blatant---and entirely
> artificial---conflict between ``be liberal with what you accept'' and
> ``be conservative with what you send.''

Historically, this is not true.  The SMTP restriction on 7 bits only
was really nothing more than an insistance (in today's lingo) that
the message be in "canonical form"...that the message is in ASCII
(not some other character set like EBCDIC) and that there is only
one way to represent ASCII -- with the seven bit code in the least
significant bits of the octet and the most significant bit set to zero.
(as opposed to setting it to one, or using it as a parity bit).
The entire purpose of the 7-bit restriction was to prevent conflicts.

As to bringing it in line with reality...it hasn't been that long
since the ietf-smtp wars in which one camp stated that we would
always be stuck with 7-bit only SMTPs and another camp stated that
there were too many people already using 8-bit SMTP that would never
switch to 7-bits only and MIME.  The argument dragged on a LOT longer
than it should have, and (IMHO) we never reached a really satisfactory
solution...we just agreed on a way for an SMTP server to signal that
it will accept 8-bit MIME messages without core dumping.

As Chair of this group, I do not wish to entertain this argument again.
However, the world has changed since the ietf-smtp wars, and there are
other forces at work that motivate changes in MTAs, and it's just remotely 
possible that a better compromise might be possible today than was possible
a few years ago.  

I'm willing to set aside a *small* amount of time at next week's WG 
meeting in Los Angeles (probably at the END of the meeting) to gauge
whether there is widespread support for encouraging 8-bit SMTP.
(I need to make out an agenda anyway).

> > clients SHOULD preferentially utilize EHLO
> 
> SMTP is already painfully slow; it'll be many years before most servers
> support ESMTP. Why not standardize the convention of putting " ESMTP"
> into the greeting line to indicate that EHLO is acceptable?

That's fine as a hint, but we already have set a direction for how a
client finds out whether a server supports EHLO.  Standardizing the
use of " ESMTP" in the greeting changes that direction and works to
the disadvantage of servers that meet the ESMTP standard but don't 
advertise such.  Since the mechanism appears not to be broken, I'd
rather not change it.

--Keith

Take the pledge! "I do not limit my speech to satisfy the whims of Congress."