To:
Daniel Manley <dmanley@tucows.com>
CC:
ietf-provreg@cafax.se, "Liu, Hong" <Hong.Liu@neustar.biz>
From:
janusz sienkiewicz <janusz@libertyrms.com>
Date:
Thu, 25 Jul 2002 13:17:40 -0400
Sender:
owner-ietf-provreg@cafax.se
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 > > > >-----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