RE: Proposed Document Changes - Pending Operations

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

Janusz,

I agree with Scott on this. Overloading an EPP field is bad for
interoperability. But I do agree with you that the changes required to
handle pending action should be kept minimum. 

On a very high level, there are two separate aspects at hand:

(1) Indicating to the client in the initial response that the requested
action is pending.
(2) Notifying the client of the result of the pending action when it is
done.

I considered (1) already resolved by introducing a new result code. This
thread is about is (2), which also have a number of issues:

(a) provide a hook in <response> to house the notification information
(b) format of the notification message (minimum set of information)
(c) whether (b) should be defined in the core or as an extension

What you have suggested is about (a). I disagree that we overload <value>
for this purpose. Besides, you still need to resolve (b) and (c). My
argument is that (b) should be defined in the core. 

I realize that Scott and I are crossing responses. I apologize that my
response is somewhat overlapped with Scott's.

I am also jumping the gun here since these issues are addressed in the draft
I am writing.

--Hong

-----Original Message-----
From: janusz sienkiewicz [mailto:janusz@libertyrms.info]
Sent: Thursday, July 25, 2002 2:46 PM
To: Hollenbeck, Scott
Cc: 'janusz sienkiewicz'; Daniel Manley; ietf-provreg@cafax.se; Liu,
Hong
Subject: Re: Proposed Document Changes - Pending Operations


If we have such 'an extension mechanism' what is purpose of this thread? Why
are we introducing new return codes and messages? The are several extension
mechanisms (<extension>, <value>) available but for some reason none of them
can be used when there is a need for protocol extension. Is this protocol
really extensible?

Janusz Sienkiewicz

"Hollenbeck, Scott" wrote:

> > The usage of <value> element could be extended.  According to
> > the epp06 spec
> > the element is used only if there is an error condition. It
> > could be also used
> > in case of success condition for passing additional
> > information. This approach
> > would allow more flexibility in the future.
>
> The "flexibility" you describe is bad for interoperability.  We already
have
> an extension mechanism to support return of additional information, and
the
> <value> element isn't part of it.
>
> -Scott-