Synopsis:
Shouldn't the server return, in a "response", the same reference Id I send in the "request"? This is not always happening. Sometimes the server includes, in the searchResponse, the reference Id I used in the initRequest, not the reference Id I used in the searchRequest. In another case I sent a reference Id in the initRequest, then omitted it in a later searchRequest. The server again returned the reference id from the initRequest.So what is the correct behavior? Should I ignore reference Id's all together unless concurrent operations is in effect?
Response:
The server should return in a "response" the reference Id sent in the "request". In a searchResponse, the value of the reference Id must be identical to the value supplied in the searchRequest, and if there was no reference Id supplied in the request, the reference Id must be omitted in the response.Thus the server behavior described above is incorrect.
Should you "ignore reference Id's all together unless concurrent operations is in effect"? Certainly, if concurrent operations is in effect the client should not ignore reference ids. In any case (whether or not concurrent operations is in effect) the client is within its rights to declare a protocol error (i.e. issue a Close with close reason 'protocol error') if the behavior violates the protocol as described above. If concurrent operations is not in effect, the client is free to ignore reference Ids. However, this clarification takes no position on the question of whether the client should ignore an incorrect reference Id (when concurrent operations is not in effect). The client may either ignore the incorrect referenceId or declare a protocol error.
Status: Approved (6/98)
Library
of Congress