Re: Proposed Document Changes - Pending Operations

[Daniel Manley <dmanley@tucows.com>]

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
>
>-----Original Message-----
>From: Patrik Fältström [mailto:paf@cisco.com]
>Sent: Monday, July 22, 2002 1:32 AM
>To: Liu, Hong; ietf-provreg@cafax.se
>Subject: RE: Proposed Document Changes - Pending Operations
>
>
>--On 2002-07-18 22.35 -0400 "Liu, Hong" <Hong.Liu@neustar.biz> 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
>
>  
>


-- 
Daniel Manley
Tucows, Inc.
Toronto, Canada
dmanley@tucows.com