Subject: RE: Proposed Document Changes

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 1 Aug 2002 11:42:52 -0400

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

---

From: janusz sienkiewicz <[email-masked]>
Date: Thu, 01 Aug 2002 12:16:12 -0400

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

---

From: janusz sienkiewicz <[email-masked]>
Date: Thu, 01 Aug 2002 15:30:01 -0400

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