[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "'Liu, Hong'" <Hong.Liu@neustar.biz>, "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Wed, 14 Aug 2002 09:39:18 -0400
Sender: owner-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.

> 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.  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."

> 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.

> 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.

Janusz made another suggestion that might be a reasonable compromise:

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

-Scott-

Home | Date list | Subject list