Hi Mark To make my point by way of example, consider a KMIP server implementation that does not support a synchronous response to a GET request. The Usage Guide [see 2.8] suggests that any client request should expect at least synchronous response support, so this example server implementation would contravene the Usage Guide. On the other hand, the KMIP Spec [see 6.7 and 6.8] says that the server decides what operations are synchronous and asynchronous, so this example server’s lack of a synchronous response to the GET request does not contravene the KMIP Spec. If the same behavior contravenes the Usage Guide while simultaneously not contravening the KMIP spec, then at least the Usage Guide and the KMIP spec must contradict each other. I am merely requesting that this contradiction (or my understanding) be corrected. If both documents are correct, then my understanding is not correct. If my understanding is incorrect, then lack of clarity in the spec may be at fault. Assuming that I do have a misunderstanding, then I would likely be assisted by answers to following questions: 1. Must a compliant KMIP server implementation support a synchronous response capability for all possible client requests? 2. May a compliant KMIP server make an on-the-fly decision [e.g. based on load conditions] whether to respond synchronously or asynchronously to a given client request? 3. Regarding KMIP Spec section 6.7, why would a compliant server not be able to respond synchronously? Regards, … Dave From: Mark Joseph [mailto:
mark@p6r.com] Sent: Wednesday, June 04, 2014 1:58 PM To: Featherstone, David;
kmip@lists.oasis-open.org Subject: Re: [kmip] - KMIP 1.2 Sync/Async - Inconsistency: Usage Guide vs Spec Hi David, I am sorry but I am not clear what your point is other than perhaps you believe Section 6.8 needs to be rewritten to make it clearer? Has there been any problem with implementations getting this feature wrong? Best, Mark Joseph, Ph.D. President P6R, Inc 408-205-0361
mark@p6r.com Skype: markjoseph_sc
http://www.linkedin.com/pub/mark-joseph/0/752/4b4 Featherstone, David <
David.Featherstone@safenet-inc.com > , 6/4/2014 9:41 AM: Greetings The Usage Guide’s section 2.8 Synchronous and Asynchronous Messages states: 197 2.8 Synchronous and Asynchronous Messages 198 The protocol allows two modes of operation. Synchronous ( mandatory ) operations are those in 199 which a client sends a request and waits for a response from the server. Polled Asynchronous 200 operations ( optional ) are those in which the client sends a request, the server responds with a 201 “pending” status, and the client polls the server for the completed response and completion 202 status. Server implementations may choose not to support the Polled Asynchronous feature of 203 the protocol. essentially saying that the server support for synchronous client requests is mandatory for all operations, whereas (additional) server support for asynchronous client requests is optional for any particular operation. However, the KMIP Spec’s section 6.8 Asynchronous Correlation Value states: 1951 6.8 Asynchronous Correlation Value 1952 This is returned in the immediate response to an operation that is pending and that requires 1953 asynchronous polling. Note: the server decides which operations are performed synchronously or 1954 asynchronously. A server-generated correlation value SHALL be specified in any subsequent Poll or 1955 Cancel operations that pertain to the original operation. essentially saying that a given operation may be supported synchronously or asynchronously at the server’s discretion . (This statement is itself somewhat ambiguous since it leaves open the possibility that a given server may support both synchronous and asynchronous response capability for the same operation, and the server’s decision to respond synchronously or asynchronously could be made dynamically. Acceptable behavior, I think, but not explicitly stated.) We may presume that the KMIP Spec allows a server not to offer synchronous support of some operations because section 6.7 Asynchronous Indicator states: 1944 6.7 Asynchronous Indicator 1945 This Boolean flag indicates whether the client is able to accept an asynchronous response. It SHALL 1946 have the Boolean value True if the client is able to handle asynchronous responses, and the value False 1947 otherwise. If not present in a request, then False is assumed. If a client indicates that it is not able to 1948 handle asynchronous responses (i.e., flag is set to False), and the server is not able to process the 1949 request synchronously, then the server SHALL respond to the request with a failure. Regards, … Dave The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.
The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.