To:
"'janusz sienkiewicz'" <janusz@libertyrms.info>, ietf-provreg@cafax.se
From:
"Hollenbeck, Scott" <shollenbeck@verisign.com>
Date:
Thu, 1 Aug 2002 11:42:52 -0400
Sender:
owner-ietf-provreg@cafax.se
Subject:
RE: Proposed Document Changes
> 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-