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-