RE: Response Code 2501

[Claus Dahl <clausd@ascio.com>]

I monitor the list and maintain the EPP client implementation at our
company. I would like to say that I agree completely that the server SHOULD
NOT send unsolicited data, and I am quite surprised the disussion has gone
on this long.

It is highly inconvenient from a client perspective to have any kind of
server initiated messages. This applies to the earlier suggested "EPP PUSH"
also. 
The pure client server approach makes client implementation much simpler.
For instance we use a simple EPP client which does session management for
efficency but otherwise adapts all communication to local interfaces, and
maintains no state. The EPP implementation is completely detached from the
rest of the system. In particular it is completely separated from all object
state concerns.
With server push or other server initiated communication, the EPP service
now has to maintain  more state than connection/session state. Highly
inconvenient and a poor separation of concerns.

Wrt "Sound technical arguments" I think the burden of proof is squarely on
the non-standard (i.e. Hong Liu's) approach. Why invent a twist on a
standard approach that is not broken? 


Claus Dahl
Ascio Technologies

-----Original Message-----
From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com]
Sent: 14. august 2002 15:39
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.

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