RE: Response Code 2501

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

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:clausd@ascio.com]
Sent: Wednesday, August 14, 2002 10:09 AM
To: 'ietf-provreg@cafax.se'
Subject: RE: Response Code 2501


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