[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "'Liu, Hong'" <Hong.Liu@neustar.biz>, ietf-provreg@cafax.se
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Fri, 19 Jul 2002 06:18:35 -0400
Sender: owner-ietf-provreg@cafax.se
Subject: RE: Proposed Document Changes - Pending Operations

> So the correct use of <status> command, under the proposed 
> change, is to
> find out whether the previous client command has been 
> successfully processed
> by the server. This does not mean that the operation requested in the
> command has been completed by the server. What I need is a 
> notification
> mechanism in EPP for the latter.

Hong,

As I said earlier, that mechanism is already present in the protocol: change
the status when completed, and notify the client by putting a message in the
queue for retrieval via the <poll> command.  The format of the notification
depends on what you want to say, just as the format of every other service
message is something to be defined by the server operator.  You might use
the client and server transaction IDs to identify the completed command in
you service message.

Hong, I don't know what's unclear about this.  To satisfy Patrik's question,
we're not (thankfully) talking about a delayed response and I'm now sure
that you haven't suggested that kind of operating mode -- we're talking
about an operation that might require third-party (maybe an offline person)
action before the requested action can be completed.  The protocol already
includes features to deal with this: object status can be determined using
the <info> command, and the server can let the client know when the offline
action has been completed using a polled message.

-Scott-

Home | Date list | Subject list