Re: Proposed Document Changes

[janusz sienkiewicz <janusz@libertyrms.info>]

In a way you are right about <renew> command. Right now <renew> is defined for
domains only and <curExpDate> ensures that the next <renew> command should
fail. But it is object extension (domain) specific.

Why using <info> may not be easy?
Any automatic processing based on <info> command will be object and  command
specific or it will based on the last modification date. Since last
modification date in <info> response is defined in object mapping document
using last modifification date makes such processing still object and command
dependant. Besides it requires perfect time synchronization between client and
server for any transform command for any object. That's why I added the
subjective part to my original opinion.

Regards,

Janusz

"Hollenbeck, Scott" wrote:

> > I would like to say a few words in defence of <status> command. Unlike
> > some other participants of the thread I see value in retaining the
> > command. It was said in the discussion that transform commands can be
> > resubmitted or their results can be determined by <info> command.
> > Retransmitting some commands could be risky (let's take <renew> for
> > example).
>
> There's no risk at all because all of the transform commands are idempotent.
> If you send the exact same <renew> command and the first command "took" but
> the response was "lost", the second command _should_ fail because the value
> of the <curExpDate> element will contain the value from before the first
> command succeeded.  If it doesn't fail the server is doing something wrong.
>
> > Using <info> command to determine the state of the
> > object may not be easy.
>
> Please explain why.  The <info> command exists explicitly to determine the
> state of an object.  Even if it _is_ hard for a client to compare the
> current state with what they think the state should be, there is no harm or
> risk in retrying a command to be sure it "took".
>
> > If a registrar enforces uniquenes of clTRID <status>
> > command provides a convenient way of handling failure situations.
>
> That's the subjective part. ;-)
>
> -Scott-