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:
,
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:
To:
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
