RE: Proposed Document Changes - Pending Operations

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

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: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