Re: Proposed Document Changes

[janusz sienkiewicz <janusz@libertyrms.info>]

A few more words regarding resubmitting transform commands in case of unknown
result of the first command. If the result of the original comand is unknown and
the same command is resubmitted and returns error we may still not know the
result of the original request. If we take <renew> as an example the fact that
the second command returned an error is not sufficient for an automated process
to make a decision whether submit it again or not. A more sophisticated process
(object and method specific) is required to make such a decision.

Regards,

Janusz



janusz sienkiewicz wrote:

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