Re: Response Code 2501

[Andrew Sullivan <andrew@libertyrms.info>]

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
<andrew@libertyrms.info>                              M6K 3E3
                                         +1 416 646 3304 x110