Mathias, 1) The new operation will be sent in whatever protocol level the TC decides. I suspect it would be major/1, minor/1. 2) Yes, that would be helpful, as far as having meaningful error processing. But in any case, the client is not going to be able to communicate with that server, so it's somewhat moot. And we've been reluctant to tell clients how to behave. 3) That's a good suggestion. We should probably say that the ProtocolVersion(s) are ordered in highest-preference first, so the server doesn't need to search until it encounters a failure-to-accommodate and back up one level. 4) Yeah, "communication session" is tricky in KMIP. This is where it was unclear as to whether our mandate from the TC was to learn what we could from TLS negotiation or to mimic it. My opinion is that if we are just learning from it, then we stop talking about the "session" concept. Bruce A Rich brich at-sign us dot ibm dot com From: Mathias Bjoerkqvist1/Zurich/IBM@IBMCH To:
indra.fitzgerald@hp.com, Bruce Rich/Austin/IBM@IBMUS Date: 03/02/2011 09:48 AM Subject: Re: [kmip] Groups - Proposal for Protocol Version Negotiation.docx uploaded Hi Indra, Bruce, I have some comments on your version negotiation proposal. Some of them were probably touched upon at the f2f and you might have considered already, but I didn't see them all explicitly addressed in your proposal. -What protocol version is used to send the Protocol Version Negotiation request? Since it cannot be v1.0, would it make sense to require (maybe in the profiles if not in the conformance section in the spec) that all client and server be able to send the request at least in some specific version (say vNext)? Otherwise the server would not necessarily be able to send the Protocol Negotiation Failure error in a message version that the client can understand. -The client would need to be able to parse and understand at least the v1.0 error response Operation Not Supported, regardless of which versions it supports. -Instead of referring to the version in the Request Header as the preferred version, could the versions listed in the request payload be sorted in order of preference by the client? -How is a "communication session" or "communication" defined? A single TLS sesson which may (or may not) be used for multiple request/response pairs? Currently a server is allowed to close the TLS connection after sending each response, and since you would not be able to batch the version negotiation with other operations you would end up in a troublesome situation. On the other hand, if we were to require the server to keep the TLS connections active, there would be other drawbacks to consider. Thanks, Mathias From:
indra.fitzgerald@hp.com To:
kmip@lists.oasis-open.org Date: 02.03.2011 00:57 Subject: [kmip] Groups - Proposal for Protocol Version Negotiation.docx uploaded The document named Proposal for Protocol Version Negotiation.docx has been submitted by Mrs. Indra Fitzgerald to the OASIS Key Management Interoperability Protocol (KMIP) TC document repository. Document Description: This proposal introduces a new KMIP operation that allows client and server to agree on a protocol version that is understood by both client and server. View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=41298 Download Document:
http://www.oasis-open.org/committees/download.php/41298/Proposal%20for%20Protocol%20Version%20Negotiation.docx PLEASE NOTE: If the above links do not work for you, your email application may be breaking the link into two pieces. You may be able to copy and paste the entire link address into the address field of your web browser. -OASIS Open Administration