[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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-

Home | Date list | Subject list