----- Original Message -----
From: "Richard O. Hammer" <ROHammer(_at_)EarthLink(_dot_)net>
To: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Monday, January 05, 2004 11:47 AM
Subject: Re: what to say on timeout?
Hector Santos wrote:
... The client drives the server. Not
the other way around.
Yes, I agree. I have not suggested that the whole SMTP be changed
from synchronous to asynchronous. I ask only if the SMTP server
should send a message with a particular error code in the circumstance
where a server decides to terminate a connection because of inactivity.
Send a 421 per RFC 2821 section 3.9.
What I am saying is if the server is going to hang up anyway, it doesn't
matter. This is about idle timeouts (long inactivity) right? In which case
the SMTP client is not in a pending wait state or waiting for any command it
can work with. If this was an interactive client, then I can only see a
usefulness if the server was going to send a "warning" the client to wake up
and do something, in which case, we don't have an appropiate client based
"noop" response code, an unsolicated information-only response code.
Since the RFC provides for 421 on one kind of asynchronous shutdown,
it would seem consistent (and polite and professional and all that) to
send some error code in event of this other kind of asynchronous
shutdown. There might be good arguments against sending such a
message, but I do not believe I have heard such arguments yet.
I hope I am not misconstrued suggesting no response should be provided.
What I am saying if you are going to hang up due to long activity, the only
thing that is useful is the response text. The code itself is meaningless
since the SMTP client would not know what to do with it. The response text
only usable in an interactive session and there again, maybe a 1 minute
warning can be sent first informing the full-duplex client to wake up.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com