Re: [kmip-interop-tech] Some specifics on the use of the TLS connection

On 11/29/2011 2:44 PM, Tim Hudson wrote: <snip> > >> 3. When a Batch Item fails, and Batch Error Continuation Option is Stop, then the Batch Count in the Response Header could be less than the Batch Count in the Request Header, and the server does not send any responses for Batch Items that followed the failing item. For example, if the client sends five batch items in a single request, and the second item fails, then the server sends Batch Count 2, and the second batch item response will carry back the Result Reason of the failing item.
> Note section 6.12 in the specification with Batch Order Option - without
> it being specified the order of execution of the batches is entirely up
> to the server implementation. The setting of this value is critical in
> interpreting how to handle failures in accordance with the batch error
> continuation option. And servers are not required to implement the Batch
> Order Option - which means all implementations have to assume that the
> order of batch execution may not be able to be controlled.  From the server point of view, though, is it the case that any as yet unprocessed Batch Items are discarded, if Batch Error Continuation Option is Stop, or, do they all need a response sent? That is, if the client sent Batch Count = 5, must the server always respond with Batch Count = 5?  Considering that whether or not Batch Order Option is sent, and whether it is TRUE or FALSE, the server could choose to process the batch items in the order they appear in the Request Message. In that case, with continuation option Stop, I don't find a Result Reason that would say, "This batch item skipped because continuation option Stop is in effect." That, and the fact that there is even a Batch Count in the Response Header, led me to believe that if the client sees a different batch count in the response, it would signify that some batch items were not processed, and expect to see a failure. Even if the batch items were processed out of order, this would still be what I would expect -- that is, a smaller batch count in the response, and one of the batch items having an Operation Failed status.  What I do in my server is process the batch items in order, and when one of them fails, return that as the last batch item in the response, truncating the batch count at that point. If I get a failure before I have any batch items to set a result for, then I return a single batch item without an Operation, which is described elsewhere in the spec. For example, if I get an unrecognized critical Message Extension.  <snip>  Regards, Jim Flood