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-