----- Original Message -----
From: "John C Klensin" <john+smtp(_at_)jck(_dot_)com>
To: "Paul Smith" <paul(_at_)pscs(_dot_)co(_dot_)uk>;
<ietf-smtp(_at_)imc(_dot_)org>
Sent: Wednesday, January 07, 2004 10:10 AM
Subject: Re: what to say on timeout?
Sigh.
Folks, I'm happy to rework the text if there is consensus that
change is actually needed, and, ideally, if someone supplies the
suggested text. However, after rereading the text, and the
predecessor text in RFC 821, it actually seems clear to me what
is intended...
Hi John,
I believe so as well.
In my view, the SMTP client has the ultimate design responsibility to decide
whether it needs to retry a transaction. Lets clarify if there is any
concern here it would be a command mode idle timeout. Request processing
timeouts is an non-issue. A 421 response is appropriate with a hangup. The
client will react accordingly when aborted.
For command mode timeouts, the client will react accordingly as well with
either non-passive or passive disconnects.
However, in my view, it is a engineering mistake to open the door to
"unnatural" and "unexpected" designs by beginning to allow for non-passive
unsolicited server notifications for command-mode timeouts.
Will it be harmless? Quite likely it will be, but I don't see why unless
you are introduction a "Wake up" Concept in which case, we need a new CODE
that identifies a "heart beat," "wake-up" or "NOOP" notification concept at
the application protocol level, not the TCP level that will minimize the
potential for a "still alive" client to use a 421 notification as part of
the next command. Otherwise you defeat the purpose. A new code is
required.
hmmmmm, lets see, you send an unsolicited 421 notification, delay the hangup
for 1 minute to see if the client will do a graceful exit (quit)? Is that
what we looking for here? Lets assume Current software will "wake up",
what happens next depends on whether it purses the notification or not. If
not, the client will exit on its own.
I'm just trying to see where the "idea" would apply. Waiting on a QUIT to
complete a transaction? What completes a transaction? I only see this when
he client completes the DATA, and receives a server notification but stills
idle now.
In my view, if we are going to have such a "Keep-Alive design" that it
should be 100% based on a SMTP client design and this can be done with no
changes to the specs:
a) SMTP client begins transaction with the MAIL FROM: command,
b) SMTP client issues the RSET to complete a transaction, and waits for new
mail.
c) Understanding per specification the server will have a minimum 5 minute
command mode idle timeout, the client SHOULD send a NOOP command to the
server every minute.
d) The client eyeballing for new queued mail begin a new transaction, go to
A:
I am just saying that we shouldn't be expecting clients to be "kept-alive."
with "wake-up warnings." as this will require a completely new framework.
Look at this way:
User agents such as Outlook with a NNTP client 100% expects passive timeout
disconnects by design. Non-passive server notifications will break the
client as the notification will be queued for the next NNTP command
response. Here also, there is no server base "NOOP" or "wakeup" server
notification code that will cause the client to wake up, purge the
unsolicited notification and do something. Instead, what I've seen some
NNTP clients issue an empty or some "redundant" command if they wanted to
keep a low timeout NNTP server alive.
If we allow for unsolicited server notifications, then in my view, we will
break more things than it solves or addresses.
Just my view on the matter.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com