RE: Proposed Document Changes - Pending Operations

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

Scott,

Thanks for the explanation. I should have mentioned in the beginning about
what I meant by "pending operation". So here is the definition: 

"A pending operation refers to a server operation requested by a client
command whose execution is pending at the time the server issues the
response to the command."

As such, the server dose NOT hold off the response to the command. In fact,
it replies with result code "Command completed successfully; action pending"
as you suggested in [i]. You put it quite correctly then that a response to
a command by the server only signals that the command has been processed
successfully. It does not necessarily mean that the operation requested in
the command has been executed prior to the server's response (although in
many cases it does). So support of pending operations does not in itself
breaks the tightly coupled command-response model of EPP. 

So yes, I was referring to the back-end processing that requires time to
complete. The most obvious one is transfer, and it has been taken care of in
EPP through special treatment. However, there are other use cases. Pending
update was the one I used as an example [ii] and you and Bruce also gave
example for "pending create" [i][iii]. I hope we can agree that these are
also valid use cases for EPP.

What I am looking for is a way to notify the client when the pending
operation is completed. Be it poll or push, we need something to put into
the message queue to indicate whether the pending operation is successful or
failed. <transfer> is treated specially in EPP so it is OK. Could you please
expand on how other pending operations may be supported by the message queue
and the <poll>? What message content shall we use and how do we identify the
pending operation in the message? I just need a solution to this problem.
Maybe an example, say for a pending create, would be very helpful.

I might have misunderstood a private email you and I exchanged regarding
using the <status> command. I will send it again to you in private. 

Thanks!

--Hong

[i]  http://www.cafax.se/ietf-provreg/maillist/2002-02/msg00038.html
[ii] http://www.cafax.se/ietf-provreg/maillist/2002-02/msg00035.html
[iii] http://www.cafax.se/ietf-provreg/maillist/2002-03/msg00000.html

-----Original Message-----
From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com]
Sent: Thursday, July 18, 2002 7:26 PM
To: Liu, Hong; ietf-provreg@cafax.se
Subject: Re: Proposed Document Changes - Pending Operations


Hong,

You read my description of the change to <status> correctly.

I'm not sure I understand what you mean by "pending operation".  Given that
all commands are supposed to receive a response immediately after being
received and processed, there should never be a situation where a command is
sent and it takes "a long time" before the server sends back a response, so
I hope that's not what you're asking about.

<HL This is not what I meant. />

If you're talking about commands like <transfer> where some back-end
processing is required before the command can be completed, we already have
mechanisms in place to check on the status of the command.  Transfer, for
example, has a query command.

We already have a mechanism in place for the server to notify clients when
such operations are completed.  That's what message queuing and the <poll>
command are for.

Your original suggestion was target more towards updates, though.  I don't
recall there being unanimous support for the changes suggested in the
message you referenced, though I agreed to pass them to the IESG as part of
he last call (I did, and there's been no reaction).  Looking at the
archives, one person said "OK" and one objected.  I also didn't say anything
about use of <status> for this purpose in my response [1].  I can't see how
it can be used as all it does is confirm that a command has been received --
it doesn't tell you if policy-driven back-end processing has been completed.

Anyway, I'm OK with the changes you suggested in March as long as no one
objects.  The change to the <status> command doesn't impact this change at
all as the "pending" status can be determined using an <info> command.

-Scott-

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

----- Original Message -----
From: "Liu, Hong" <Hong.Liu@neustar.biz>
To: <ietf-provreg@cafax.se>
Sent: Thursday, July 18, 2002 6:45 PM
Subject: RE: Proposed Document Changes - Pending Operations


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