Subject: RE: Proposed Document Changes

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 1 Aug 2002 19:51:46 -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.

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-

---

From: janusz sienkiewicz <[email-masked]>
Date: Fri, 02 Aug 2002 14:12:41 -0400

Defending <status> command I assumed wrong interpretation of the command
description. My intepretation was (assuming uniquness of clTRID):

Response with empty <status> - command not processed
Response with positive ack attribute - command processed, success
Response with negative ack attribute - command processed, failure

That was the only interpretation, I could figure out, that was making the
command usefull. After your clarification I agree that there is not much value
in keeping the command.

Regards,

Janusz