Subject: RE: Proposed Document Changes - Pending Operations

From: "Liu, Hong" <[email-masked]>
Date: Mon, 22 Jul 2002 16:42:07 -0400

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

-----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: Daniel Manley <[email-masked]>
Date: Thu, 25 Jul 2002 12:02:00 -0400

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

-- 
Daniel Manley
Tucows, Inc.
Toronto, Canada
[email-masked]

---

From: janusz sienkiewicz <[email-masked]>
Date: Thu, 25 Jul 2002 13:17:40 -0400

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