Re: Proposed Document Changes

[janusz sienkiewicz <janusz@libertyrms.info>]

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


"Hollenbeck, Scott" wrote:

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