RE: Response Code 2501

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

Scott,

I could not find the section in RFC1132, maybe you referred to a different
RFC number. In any case, I did check the FTP RFC959, where result code 421
is defined in FTP for a similar purpose as 2501 for EPP.

It is good that you brought up FTP as an example to shed lights on how 421
is being used. My colleague Ning Zhang collected an FTP trace yesterday from
an WFTP implementation on Linux. The trace clearly shows that the FTP server
sends 421 to the client before closing down the control connection after
timeout. 

So, should result code 2501 be handled similarly in EPP in the case of
server closing down the session?

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com]
Sent: Monday, August 12, 2002 3:58 PM
To: 'Liu, Hong'; 'ietf-provreg@cafax.se'
Subject: RE: Response Code 2501


> I am looking for a solution to problem of server terminating session
> management. I will be happy if you or someone else can give me an
> alternative solution.

I think the way that ftp servers deal with this is an excellent example; see
section 4.1.3.2 of RFC 1132.  The ftp control connection can be closed by
the server after a period of client inactivity.  There's no
message/response/error code sent to the client because the server only
responds to commands, just as in EPP today.  If/when the client next tries
to do something (if ever), it finds that the connection has been closed and
the situation is reported to the user.

BTW, the mapping of a session to the concept of a connection to a server is
being addressed in the next edition of the documents.  I'm not saying that
we get tied to connection-oriented transports like TCP in the core document,
but as part of the whole stateful vs. stateless issue Patrik wanted to see a
clearer mapping between the session and connection concepts.  Transport
documents are going to have to be specific about how sessions are mapped to
client-server connections.

-Scott-