RE: Proposed Document Changes - Pending Operations

["Liu, Hong" <Hong.Liu@neustar.biz>]

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:janusz@libertyrms.com]
Sent: Thursday, July 25, 2002 1:18 PM
To: Daniel Manley
Cc: ietf-provreg@cafax.se; 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
> >
> >-----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