Subject: RE: Proposed Document Changes - Pending Operations

From: "Liu, Hong" <[email-masked]>
Date: Thu, 18 Jul 2002 18:45:59 -0400

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:[email-masked]]
Sent: Wednesday, July 17, 2002 5:57 PM
To: [email-masked]
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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 18 Jul 2002 19:25:35 -0400

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.

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

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 19 Jul 2002 08:47:53 +0900

--On 2002-07-18 19.25 -0400 "Hollenbeck, Scott" <[email-masked]>
wrote:

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

I explicitly want to know whether this wg _really_ want to have what I
would call "delayed execution" or not. I heard from Scott and the wg chairs
when we had lunch that the wg has not wanted delayed execution.

I am even prepared saying that I don't see any need for either delayed
execution or pipelining in the protocol. It makes the protocol MUCH more
difficult. The current protocol do not handle either delayed execution or
pipelining, so if you want either of these things, you really have to go
back to the drawing board.

Scott and wg chairs told me the wg have not expressed interest in those
"features", and that the wording which is used today is possibly there
because of misunderstanding whether words are needed in the core protocol
or the protocol binding. This I think is much better if the changes Scott
propose are applied.

  paf