RE: Proposed Document Changes - Pending Operations

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

Scott,

I do have a concern about the proposed change for the use of <status>
command that I hope you will address. 

Do you imply that <status> command can now only be used for checking the
last unacknowledged command from the client? If so, what mechansim is
available for the client to check the status of a pending operation [a]? I
recall in that discussion, you suggested that the <status> command be used
for that purpose. I assume that you will incorporate the changes suggested
in [a] to the final EPP documents.

I have no objection to the change as long as there is an alternative for the
server to notify the client about the completion of a pending operation. May
I suggest that we add two new result codes: "Pending operation successful"
and "Pending operation failed" for that purpose? 

Another related issue is how the server identify the pending operation.
Since with the proposed change, the server only caches the client
transaction identifier for the last command processed, it will not have it
available when it completes the pending operation (presumably after many
other commands processed in between). Should the server transaction ID be
used instead?

I hope that I won't be penalized for speaking up, -:)

Thanks!

--Hong

[a] http://www.cafax.se/ietf-provreg/maillist/2002-03/msg00006.html

-----Original Message-----
From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com]
Sent: Wednesday, July 17, 2002 5:57 PM
To: ietf-provreg@cafax.se
Subject: Proposed Document Changes


[snip...]

- The description of the <status> command should be changed to describe the
server's caching responsibilities.  We agreed that the server should only be
responsible for caching the identifier for the last command processed, thus
if a response isn't received the client should send a <status> command
before sending any subsequent commands.  This should make <status>
processing a lot easier for the server, and it's consistent with the
protocol's command-response operating mode.  It might also make sense to
make the client transaction identifier mandatory instead of optional if the
server doesn't have to cache identifiers for "a long time".

[snip...]

If anyone has any issues or concerns with the above, speak up!

-Scott-

[1]
http://www.cafax.se/ietf-provreg/maillist/2002-06/msg00015.html