RE: Response Code 2501

["Liu, Hong" <Hong.Liu@neustar.biz>]

Scott,

I insisted on keeping this option open for implementation because I feel
strongly that this is the right thing to do. 

Is this an exception to the rule? Yes, it is because it handles an
exceptional case: server-initiated session termination. This unsolicited
response is _only_ sent at the end of a session. This unsolicited response
is _not_ used anywhere else during the session.

Has this be done before? Yes, the same approach was taken in most existing
FTP implementations. Why we use FTP as a reference point? Because FTP has to
handle the same problem as in EPP. And the best common practice in FTP
server implementations today is to send an unsolicited response to the
client before the server closes the connection. More information is provided
below.

Why this is useful? It helps a client to find out why the session is gone.
Otherwise, how can one tell that it is because of the server timeout or
because of network problems? So this is a hint from the server to the client
why the session is gone, not a mechanism for the client to detect the lose
of a session.

BTW, what I am asking is to leave it as an implementation option. If a
server implementation does not want to do this, it is OK. If a client
implementation does not want to pick up the last server message in the
buffer after detecting the session is gone, that is OK, too. Why? Because it
does not affect in any way the "normal" EPP operations in any way. But a
server implementation should be allowed to do so if it chooses to. And a
client implementation should be allowed to take advantage of this diagnosis
mechanism after detecting the lose of a session. 

I hope we can think of this issue more carefully before jumping into
conclusion that this should be excluded.

I have to leave this discussion for now since I will be out of town in the
next two weeks. I probably won't be able to access the list in the next
couple of days, but I will try to be back next Monday. In the meantime, as
you said before, silence != concurrence, -:)

More comments in line enclosed with <HL/>.

--Hong 

-----Original Message-----
From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com]
Sent: Wednesday, August 14, 2002 9:39 AM
To: 'Liu, Hong'; 'ietf-provreg@cafax.se'
Subject: RE: Response Code 2501


> I know what it says in RFC959, and I also looked carefully at 
> the tcpdump in
> one of the most popular FTP implementations. Sometimes, we 
> get too bolted
> down to interpret the standard literally. Are you going to 
> say that the
> Linux implementation is not confirming to RFC959?

If it's sending an unsolicited response, yes, my interpretation would be
that it's not conforming as the text in 959 is pretty clear to me about 421
being a _response_.  Interpreting standards literally is what ensures
interoperability.

<HL> 
What I meant is that RFC959 does not explicitly exclude _unsolicited_
response. Yes, it is odd. But it is the approach taken by most of the FTP
server implementations today. Are you going to say they are all
non-conforming? Then where is the conforming one? I am not aware of any
major FTP interoperability issues because of this one.
</HL>

> As I explained before, server initiated session termination is not a
> "normal" operation that fits into the client-request 
> server-response mode.
> Having the server send the last message notifying the client 
> that it is
> closing down the session makes a lot of sense for the client 
> to figure out
> later on why the session is gone.

Dead or hung clients aren't going to figure anything out.  

<HL> 
This is just bad client implementation. Sorry, that is the only way I can
say. A client should not be dead or hung just because the session is gone.
For example, an FTP client is not dead or hung when the connection is lost.
</HL>

If anything,
section 4.1.2.11 of RFC 1123 clearly says that the client should detect
connection closure without interpreting response code 421 in any special
way:

"A User-FTP SHOULD NOT interpret a 421 reply code ("Service
not available, closing control connection") specially, but
SHOULD detect closing of the control connection by the
server."

<HL>
Actually, I don't see a problem here. As I explained above, an FTP client
does not use it to detect the closing of a connection. It simply fetches
that message and displays it to the user why the connection is gone, _after_
it detects that the connection is closed.
</HL>

> You got to have a sound technical argument why you are 
> against it instead of
> just saying that it does not fit into the client/server model, because
> existing client/server implementation, i.e., FTP, does use 
> the unsolicited
> response before terminating a session.

The sound technical argument has already been provided: a passive server
should not be sending a response to a client in the absence of a command.
An implementation of another protocol that does something different is not a
good example of a counter argument.

<HL>
You brought up the FTP example, and I agreed that it is a good example to
learn how other protocols handle similar situation. Why do we invent
something against a common practice that has proven to work very well over
so many years? 
</HL>

> If necessary, I will post the trace to the list for your reference.

Feel free, but it's not needed for my reference.  I've already seen it for
myself.

Since we continue to disagree (though as far as I can tell you're the only
one who has objected to removing this response code), I'll defer to the
chairs to determine WG consensus.  Even if popular ftp implementations are
sending unsolicited responses, I don't think that we should.

<HL>
I hope that this WG can keep the IETF principle of "rough consensue and
running code". Here are the FTP running codes I would like to share with the
WG:

FTP servers:

Solaris 5.8				 ?		421 Timeout (900
seconds): closing control connection.
HP-UX B.11				1.1.214.6	421 Service not
available, remote server has closed connection
RedHat Linux 7.1			wu-2.6.1-16	421 Timeout (900
seconds): closing control connection.
Windows NT: ftp.microsoft.com	 ?		421 Timeout (180 seconds):
closing control connection.
ProFTPD Server: ftp.sf.net	 ?		421 No Transfer Timeout (600
seconds): closing control connection.
NcFTPd: ftp.cdrom.com (FreeBSD)?		421 Disconnecting you since
you were inactive for 300 seconds.	
	
Other popular FTP servers, such as ftp.uu.net, nic.funet.fi, would behave
the same way as above. WS_FTP server sends the following spontaneous reply
"500 connection timed out" before closing the connection. The result code is
different, but the principle remains the same.

I think it is a _very_ good idea to draw upon previous protocol
implementation experiences when designing new protocols. To me, it just
makes a lot of sense. Of course, I would love to see others from IETF to
share their thoughts on why most FTP implementations are done this way.
</HL>

Janusz made another suggestion that might be a reasonable compromise:

http://www.cafax.se/ietf-provreg/maillist/2002-08/msg00062.html

<HL>
I don't think it is a bad idea, but why invent a new EPP command for the
same purpose? You still need an XML structure similar to <result> inside
<goodbye> to explain why the session is closed. But I will keep an open mind
and think through it a bit more on the airplane...
</HL>

-Scott-