[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 19:51:46 -0400
Sender: owner-ietf-provreg@cafax.se
Subject: RE: Proposed Document Changes

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

If you consider parsing of the response to an <info> command and doing some
comparisons sophisticated, you may be right -- but that's not the point.

All the <status> command does/did was confirm that a command was received
and processed.  It does _not_ tell you if the command succeeded or failed --
that's what responses are for, and that's why the necessity of the command
has been questioned.

Now, this might lead us back to the "well, what if a response is lost"
argument?  That's why we have reliable transports, transaction identifiers,
query commands, and idempotent transform commands.

-Scott-

Home | Date list | Subject list