Message-ID: <clBPnF600WBwEm3MAf@andrew.cmu.edu>
Date: Thu, 29 Feb 1996 09:48:49 -0500 (EST)
From: John Gardiner Myers <jgm+@CMU.EDU>
To: drums@cs.utk.edu
Subject: Re: comments from a newcomer
In-Reply-To: <199602290140.UAA15332@wilma.cs.utk.edu>
References: <199602290140.UAA15332@wilma.cs.utk.edu>

Keith Moore <moore@cs.utk.edu> writes:
> The real point here, I think, was that a server should not simply
> close a connection without sending some error code.

A point with which I strongly and emphatically disagree and have
objected to multiple times on this list.

Clients already have to deal with a connection simply closing without
some error code and they have to deal with this as a temporary
failure.  This condition can arise due to conditions outside of the
server's control, for example a network failure.

The best I can figure, this change is intended to address the problem
with some braindamaged servers which would close the connection in
response to unrecognized commands.  That particular problem should be
addressed by being more specific about server behavior in the face of
unrecognized commands, syntax errors, and the like.

Reply codes should only be sent when they directly pertain to a
pending command.  That is the SMTP model of replies--SMTP has no
facility for returning "out of the blue" codes, similar to the
"untagged data" feature of IMAP.  Giving clients "out of the blue"
reply codes which they're going to associate to some random command is
simply going to cause trouble.

Servers closing the connection on a timeout is a non-problem.
Changing this aspect of SMTP is likely to cause problems.  Since I
have objected to this change multiple times on this list and since
nobody has addressed my concerns with any counterarguments, the change
should be flushed from the document.

-- 
_.John G. Myers		Internet: jgm+@CMU.EDU
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up