Subject: RE: Proposed Document Changes - Pending Operations

From: "Liu, Hong" <[email-masked]>
Date: Thu, 18 Jul 2002 22:28:37 -0400

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:[email-masked]]
Sent: Thursday, July 18, 2002 7:26 PM
To: Liu, Hong; [email-masked]
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" <[email-masked]>
To: <[email-masked]>
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:[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: Fri, 19 Jul 2002 06:18:35 -0400

> So the correct use of <status> command, under the proposed 
> change, is to
> find out whether the previous client command has been 
> successfully processed
> by the server. This does not mean that the operation requested in the
> command has been completed by the server. What I need is a 
> notification
> mechanism in EPP for the latter.

Hong,

As I said earlier, that mechanism is already present in the protocol: change
the status when completed, and notify the client by putting a message in the
queue for retrieval via the <poll> command.  The format of the notification
depends on what you want to say, just as the format of every other service
message is something to be defined by the server operator.  You might use
the client and server transaction IDs to identify the completed command in
you service message.

Hong, I don't know what's unclear about this.  To satisfy Patrik's question,
we're not (thankfully) talking about a delayed response and I'm now sure
that you haven't suggested that kind of operating mode -- we're talking
about an operation that might require third-party (maybe an offline person)
action before the requested action can be completed.  The protocol already
includes features to deal with this: object status can be determined using
the <info> command, and the server can let the client know when the offline
action has been completed using a polled message.

-Scott-

---

From: "Liu, Hong" <[email-masked]>
Date: Mon, 22 Jul 2002 10:41:01 -0400

Patrik,

Thanks for the clarification. At least we have consensus on the definition,
-:)

I initially thought that Scott and I were discussing means to achieving
this. But now you are suggesting that EPP shoud not support such operations.
I want to know why.

Now I think we have a big issue at hand if this capability is striped out of
the protocol at the last minute. This is not what I want to do, this is what
the reality of registry operations calls for. There are many cases where
instant execution of a requested operation on a server object is not
possible. This is particularly true for sponsored TLDs and/or ccTLDs where
registry policy requires that an operation be authorized before execution.
Take .au and .kids.us for example. There are also cases for advanced
services offered by unsponsored registries that need this capability.

Please tell me what I have available to accommodate these use cases? I don't
buy the idea that this has to be done outside of EPP since this is a generic
scenario. In addition, even for out-of-hand solutions, the response from the
server, step (2) in your definition, still does not mean the completion of
the command. So we are back to square zero.

--Hong

-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]]
Sent: Monday, July 22, 2002 1:32 AM
To: Liu, Hong; [email-masked]
Subject: RE: Proposed Document Changes - Pending Operations

--On 2002-07-18 22.35 -0400 "Liu, Hong" <[email-masked]> wrote:

> I guess we had different definition for "delayed execution". Please refer
> to my response to Scott's email. In short, pending operation does not
> call for delayed response. In fact, it calls for additional information
> once the pending operation is completed.

This is exactly what I mean by "delayed execution".

I.e.:

(1) Client send a command to server
(2) Server respond that it has received command
(3) Server execute the command
(4) Client fetches the result code

This is what I urge this wg to _not_ do.

If you really need asynchronous execution like this (i.e. even delayed
execution like this), you have to (a) convince the IESG that is needed and
(b) redesign the protocol quite extensively, because what you want to do is
not possible with what you have on the table today.

    paf

---

From: "Liu, Hong" <[email-masked]>
Date: Thu, 25 Jul 2002 12:56:07 -0500

Janusz,

I understand what you suggested, but I would like to have Scott comment on
the use of <value> element within <result>. On page 12 of epp-06, it states
that:

 " - Zero or more OPTIONAL <value> elements that echo client-provided
  elements (including XML tag and value) that caused server error
  conditions."

In syntax, it can be used as a hook for what I want, but in semantics, this
element is not defined for that purpose. Do we really want to overload the
use of this element? I would prefer to add another OPTIONAL element such as
<notify> in <result> instead.

I am writing a draft for the uniform treatment of pending action in EPP,
hopefully to get it done by this weekend. So stay tuned...

--Hong

-----Original Message-----
From: janusz sienkiewicz [mailto:[email-masked]]
Sent: Thursday, July 25, 2002 1:18 PM
To: Daniel Manley
Cc: [email-masked]; Liu, Hong
Subject: Re: Proposed Document Changes - Pending Operations

I don't think any particular changes are required tp epp protocol to
acomplish
Hong's objective. In epp06 <result> element has child  <value> element. The
definition of <value> element in epp06 is more flexible than in epp02 (it
allows
xml extensions). I think <value> element could be used to indicate that the
last
operation is pending.

Janusz

Daniel Manley wrote:

> Just to chime in here...
>
> I like the steps described by Hong here -- a very natual use of the poll
> mechanism.  I understand from recent postings by Scott and Hong that a
> new "Command completed successfully; action pending" response code/text
> will be added to the base draft.  I believe this is crutial for the
> steps described below.  It allows the registrar to reliable pass the
> message on to the registrant that the registry is not quite finished the
> operation.
>
> I think Hong was also looking for a well-defined and reliable schema for
> poll responses.  IMHO, the typical notification messages would look like
> responses to <transfer op="query">, <renew>, <delete> and <info>
> commands.  I do see that sending an <info> response and leaving it up to
> the registrar to figure out what changed isn't the greatest idea.
>  Though registrars could build their systems to expect "predictable"
> change to an object based on the "...action pending" response to the
> previous command on that object.  Otherwise, we'd have to build a
> notification message shema to describe a change on an object (removal of
> a status, addition of another property, etc...).
>
> Dan
>
> Liu, Hong wrote:
>
> >Patrik,
> >
> >Rick Wesson has suggested that I reword my response to you to clarify the
> >issue. So here is my second try. This time, I will use an example to make
it
> >more concrete.
> >
> >Suppose the registry policy requires that every name registered go over a
> >formal review before the request for registration is granted. So here is
the
> >typical flow of client (C, registrar) and server (S, registry)
interactions,
> >in the context of the four steps you outlined:
> >
> >(1) C sends a <create> command to the server, requesting for a name X.
> >(2) S accepts X, changes its status to "pendingVerification", and sends a
> >response back to C indicating command success.
> >At this point, X is not registered, but is reserved so that no one else
can
> >take it while it is under review.
> >(3) The registry completes the review and grants the registration. S
removes
> >the "pendingVerification" status and puts a notification into the message
> >queue.
> >(4) C polls and gets the notification from S that registration for X has
> >been approved.
> >
> >What I meant by pending operation (or delayed operation in your word) is
> >that at step (2), the response from S merely says that the request for
> >registering X by C is received and the review process has started. The
> >decision on whether the request will be eventually granted is pending for
> >further review. So from EPP perspective, the command-response transaction
> >may be regarded as completed by the end of step (2). However, from
> >operations perspective, neither C nor S considers that the request for
> >registering X is completed. I think that is where the misunderstanding
kicks
> >in.
> >
> >I hope this example explains what I meant by "pending operation". And I
hope
> >that you would not object to allowing EPP to do things like this. Of
course,
> >I am open to using any term that helps to avoid the confusion.
> >
> >What Scott and I were discussing is about ways to format the notification
in
> >step (3). Scott has already started another thread on this issue [1]...
> >
> >--Hong
> >
> >[1] http://www.cafax.se/ietf-provreg/maillist/2002-07/msg00038.html
> >
> --
> Daniel Manley
> Tucows, Inc.
> Toronto, Canada
> [email-masked]

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 25 Jul 2002 14:24:02 -0400

> The usage of <value> element could be extended.  According to 
> the epp06 spec
> the element is used only if there is an error condition. It 
> could be also used
> in case of success condition for passing additional 
> information. This approach
> would allow more flexibility in the future.

The "flexibility" you describe is bad for interoperability.  We already have
an extension mechanism to support return of additional information, and the
<value> element isn't part of it.

-Scott-

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 25 Jul 2002 15:05:00 -0400

> If we have such 'an extension mechanism' what is purpose of 
> this thread? Why
> are we introducing new return codes and messages? The are 
> several extension
> mechanisms (<extension>, <value>) available but for some 
> reason none of them
> can be used when there is a need for protocol extension. Is 
> this protocol
> really extensible?

The whole question is ultimately one of "does this belong in the core
protocol" or "does this belong in an extension".  It seems to me, based on
list discussion over the last two years, that the concept might be of
general enough interest to be in the core protocol.

I haven't seen anyone (other than you above) suggest that the existing
extension mechanisms can't be used.  I disagreed with your assertion of the
<value> element being an appropriate place to park "pending" information
because the <value> element isn't part of the existing extension framework.
In truth it would be quite easy to define an extension, but given that we
already have the concept of offline verification before provisioning an
object in the domain mapping document (and have had it in there for a while)
it seems logical to be consistent when dealing with updates that require
offline verification.

If you disagree with the premise of Hong's suggestion being generally
useful, thus being something that should be punted to an extension, please
explain why.

The answer to your last question is an unqualified "yes".

-Scott-

---

From: "Liu, Hong" <[email-masked]>
Date: Thu, 25 Jul 2002 14:19:57 -0500

Janusz,

I agree with Scott on this. Overloading an EPP field is bad for
interoperability. But I do agree with you that the changes required to
handle pending action should be kept minimum. 

On a very high level, there are two separate aspects at hand:

(1) Indicating to the client in the initial response that the requested
action is pending.
(2) Notifying the client of the result of the pending action when it is
done.

I considered (1) already resolved by introducing a new result code. This
thread is about is (2), which also have a number of issues:

(a) provide a hook in <response> to house the notification information
(b) format of the notification message (minimum set of information)
(c) whether (b) should be defined in the core or as an extension

What you have suggested is about (a). I disagree that we overload <value>
for this purpose. Besides, you still need to resolve (b) and (c). My
argument is that (b) should be defined in the core. 

I realize that Scott and I are crossing responses. I apologize that my
response is somewhat overlapped with Scott's.

I am also jumping the gun here since these issues are addressed in the draft
I am writing.

--Hong

-----Original Message-----
From: janusz sienkiewicz [mailto:[email-masked]]
Sent: Thursday, July 25, 2002 2:46 PM
To: Hollenbeck, Scott
Cc: 'janusz sienkiewicz'; Daniel Manley; [email-masked]; Liu,
Hong

If we have such 'an extension mechanism' what is purpose of this thread? Why
are we introducing new return codes and messages? The are several extension
mechanisms (<extension>, <value>) available but for some reason none of them
can be used when there is a need for protocol extension. Is this protocol
really extensible?

Janusz Sienkiewicz

---

From: "Liu, Hong" <[email-masked]>
Date: Thu, 25 Jul 2002 14:52:38 -0500

Scott,

I have a couple of questions for clarification regarding object with pending
action:

Does EPP stipulate that at most one pending action is allowed per object?

To go a bit further, does EPP prohibit any transformation operation on an
object with a pending action? 

Of course, query-type of operations should be allowed.

Thanks!

--Hong

---

From: "Liu, Hong" <[email-masked]>
Date: Thu, 25 Jul 2002 15:09:18 -0500

Scott,

Another couple of questions for clarification. It seems that the <status>
command will be removed from EPP. 

Do you still plan to make the clTRID mandatory for all EPP commands? 

Is clTRID required to be unique, if present, per client? It seems so in the
spec, but I heard people say otherwise.

Thanks!

--Hong

---

From: "Liu, Hong" <[email-masked]>
Date: Thu, 25 Jul 2002 16:56:07 -0400

Janusz,

That is exactly the problem I had when I first raised the issue on the list.
I fully understand your concerns about complexity. In my upcoming draft, I
will present a few options, and hopefully the WG will choose one with
minimum impacts on the core documents. 

Cheers,

--Hong

-----Original Message-----
From: janusz sienkiewicz [mailto:[email-masked]]
Sent: Thursday, July 25, 2002 4:32 PM
To: Hollenbeck, Scott
Cc: Daniel Manley; [email-masked]; Liu, Hong
Subject: Re: Proposed Document Changes - Pending Operations

Scott, Liu,

It is true that a trace of 'the concept of offline verification before
provisioning an object ' can be found in domain mapping document. The
problem
is the part of the document that deals with the subject is very vague. There
is
not much guidance have to use the concept. Such a concept does not exist at
XML
schema definition level. I think more work is required on definition and
refinement of the concept. New result codes and errror conditions could be a
result of the process.

I assume such a definition is a nontrivial task. That's why I suggested  a
solution based on generic extension mechanism. It could be a quick
potentially
temporary solution. From Liu's note I assume he is going to prepare
something
in the matter. I hope it will fill the gaps I can see in domain mapping
document.

Janusz Sienkiewicz