Subject: Response Code 2501

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 12 Aug 2002 10:52:12 -0400

While working through the new state diagram to be added to the EPP core
document, I had to ponder idle timeouts and they're addressed.  Right now
there's an error code defined that allows a server to notify a client of a
timeout situation:

2501 "Timeout; server ending session"

Is this error code really needed, though?  Servers aren't supposed to send a
response to a client without having first received a command, so if a client
dies or creates a session that's been alive for "a long time" the server
shouldn't be sending this as an unsolicited response.  It seems to make more
sense in this case for the server to just close the connection, and if the
client tries to write something it'll find the connection closed.

Thoughts?

FWIW this and the TCP header thing are the last two things I need to address
before being able to release the updated documents.

-Scott-

---

From: "Gould, James" <[email-masked]>
Date: Mon, 12 Aug 2002 12:22:00 -0400

Scott,

I don't see value in the 2501 response, since as you indicated the server is
not supposed to send an unsolicited response.  Even if the server sends the
response before closing the connection, the client will most likely not be
in a state to read it.  From a protocol perspective, simply closing the
connection would be more straight forward and would not introduce
unsolicited packets.  

Jim 

> ----------
> From: 	Hollenbeck, Scott
> Sent: 	Monday, August 12, 2002 10:52 AM
> To: 	[email-masked]'
> Subject: 	Response Code 2501
>

---

From: "Liu, Hong" <[email-masked]>
Date: Mon, 12 Aug 2002 15:29:53 -0400

Scott,

I should have clarified better what I meant by "normal" in the previous
email. I would also like to distinguish between session and connection in my
posting, too.

By "normal" operation, I mean the client/server exchange after the session
is established. The issue at hand has to do with session management, rather
than a response to a command. Terminating a session does not necessarily
triggers the termination of the underlying transport connection. I hope that
we can address this issue in EPP without being completely tied to the TCP
mapping.

At present, a client can notify the server to terminate a session via a
<logout> command. However, it is not clear in EPP how a server should
terminate a session on its own end. The use of 2501 at least provides a way
for the server to notify the client that it is closing down the session due
to timeout. The client is not necessarily dead and hung at this point. So it
will be able to retrieve the message from its buffer.

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.

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Monday, August 12, 2002 11:58 AM
To: 'Liu, Hong'; [email-masked]'
Subject: RE: Response Code 2501

> While I understand that the normal operating mode for EPP is
> client-initiated command/response, this is a special case 
> where the server
> initiates the action due to non-activity by a client. 
> Otherwise, the client
> will be left without any clue why the connection is gone.

Hong,

It's not just the "normal" operating mode, it's the _only_ operating mode
currently defined.  If the client is dead or otherwise hung, a clue isn't
going to help.

I'm OK with leaving this response code in if it might have some future
benefit (like if someone ever writes a draft describing server message
pushing ;-)), but as things are written currently I'd consider a server that
sends an unsolicited 2501 response to be non-conforming.

-Scott-

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 12 Aug 2002 15:57:34 -0400

> management. I will be happy if you or someone else can give me an

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-

---

From: "Liu, Hong" <[email-masked]>
Date: Tue, 13 Aug 2002 12:21:04 -0500

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:[email-masked]]
Sent: Monday, August 12, 2002 3:58 PM
To: 'Liu, Hong'; [email-masked]'
Subject: RE: Response Code 2501

-Scott-

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 13 Aug 2002 19:51:22 -0400

> is defined in FTP for a similar purpose as 2501 for EPP.

Oops, sorry, it's RFC 1123.

> sends 421 to the client before closing down the control 

Looking at RFC 959, I don't agree at all that the situation is similar.
Response code 421 is clearly identified as a _response_ sent for the various
ftp commands, not an unsolicited response to note connection closing as a
result of a timeout:

"421 Service not available, closing control connection.
This may be a reply to any command if the service knows it
must shut down."

> server closing down the session?

Nope.  No unsolicited responses.

-Scott-

---

From: "Liu, Hong" <[email-masked]>
Date: Tue, 13 Aug 2002 20:34:20 -0400

Scott,

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?

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.

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.

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

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Tuesday, August 13, 2002 7:51 PM
To: 'Liu, Hong'; [email-masked]'
Subject: RE: Response Code 2501

[snip...]

-Scott-

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 14 Aug 2002 09:39:18 -0400

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

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

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

---

From: Claus Dahl <[email-masked]>
Date: Wed, 14 Aug 2002 16:09:11 +0200

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:[email-masked]]
Sent: 14. august 2002 15:39
To: 'Liu, Hong'; [email-masked]'
Subject: RE: Response Code 2501

-Scott-

---

From: "Liu, Hong" <[email-masked]>
Date: Wed, 14 Aug 2002 23:23:47 -0500

Claus,

Instead of repeating my arguments, I refer you to my response to Scott...

This issue has nothing to do with EPP PUSH or unsolicited response in
general. It is exception handling at the end of a server terminating
session.

Implementing a good EPP client that works well is by no means easy. We have
been there, done that. However, handling this is the least that you need to
worry about: you can choose to ignore it if you want. So the complexity
argument does not hold.

I hope you can take back the non-standard accusation. We are still in
discussion about EPP. We did not invent any twist to the protocol. Quite to
the contrary, we are following sound common practices that have proven to
work well in the past.

To the WG Chairs: I hate to use the strong language above, but I reserve the
rights to defend myself against any careless and false accusations.

--Hong

-----Original Message-----
From: Claus Dahl [mailto:[email-masked]]
Sent: Wednesday, August 14, 2002 10:09 AM
To: [email-masked]'
Subject: RE: Response Code 2501

Claus Dahl
Ascio Technologies

---

From: "Liu, Hong" <[email-masked]>
Date: Sat, 17 Aug 2002 15:17:59 -0500

Andy,

I see your points. Believe me, I'd love to make it mandatory. However, I am
not sure if that is the only problem you had for keeping it in EPP.

--Hong

-----Original Message-----
From: Andrew Sullivan [mailto:[email-masked]]
Sent: Thursday, August 15, 2002 10:13 AM
To: [email-masked]'
Subject: Re: Response Code 2501

On Thu, Aug 15, 2002 at 12:03:24AM -0400, Liu, Hong wrote:

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

That seems to me like the worst of all possible worlds.  I cannot see
any advantage is having session-control messages be optional.  Either
the specification requires these control messages, or not.  If it is
optional, client implementors at least have to build in the ability
to handle the message in case it arrives.

What's worse, if it's optional, the client won't know if the failure
to receive the message is because the server doesn't support it, or
because the network went away, or anything else.  Since that very
ambiguity is what the message is supposed to be solving, making the
"response" code optional just pushes the ambiguity deeper.  Of
course, one could add a bunch of stuff in the session initialisation
to say whether the message is supported; but that means building in a
bunch more overhead in order to support a message that is outside the
passive-server model anyway.  Seems like a bad idea, at least to me.

A
-- 
----
Andrew Sullivan                               87 Mowat Avenue 
Liberty RMS                           Toronto, Ontario Canada
<[email-masked]>                              M6K 3E3
                                         +1 416 646 3304 x110