OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [kmip] Groups - Split_Key_Proposal_v0.5.docx uploaded


Hi Bruce,

You're right that I included the Object Type in Create Split Key to mimic the Create request. I don't think it's needed and am happy to take it out - you're not the first person to point this out. I'm less certain that it's unnecessary in Join Split Key - I could make the Object Type optional in the Join Split Key request. What do you think?

Kelley

On Apr 23, 2013, at 7:11 AM, Bruce Rich wrote:

Kelley,

A couple of questions regarding the required ObjectType input parameter.  It kinda makes sense on JoinSplitKeys (maybe).  I don't quite get why it's a required input on CreateSplitKeys, and exactly what it should be, given that the server is supposed to object if the wrong ObjectType is specified.  

I suspect that you were more or less reflecting the Create operation for a SymmetricKey, where it's a required input parameter.  At this point, I think its presence on that API is vestigial, that at one point, Create was anticipated to be the mechanism for all object creation, but later we realized that the input parameters were going to be different for different object types, so what made sense at a high level made no sense at a lower level, but we never circled back around and removed it.

However, if the ObjectType is meaningful as input on CreateSplitKeys, then you need to discuss how the server would behave differently based on the value supplied as input.  And I guess that really also applies to JoinSplitKeys...how should the server behave differently based on the ObjectType requested?  If no behavioral changes are implied, then I don't see why it's there.  And if behavioral changes are implied, then we need to spell them out so that we can get interoperability.

And I'm OK with the Link discussion in the Usage Guide, given that it's non-normative and relegated to client optional behavior.

Bruce A Rich
brich at-sign us dot ibm dot com




From:        Kelley Burgin <kwburgi@tycho.ncsc.mil>
To:        kmip@lists.oasis-open.org
Date:        04/16/2013 05:42 AM
Subject:        [kmip] Groups - Split_Key_Proposal_v0.5.docx uploaded
Sent by:        <kmip@lists.oasis-open.org>




Submitter's message
Includes Usage Guide text.
-- Mr. Kelley Burgin
Document Name: Split_Key_Proposal_v0.5.docx

Description
Updated Split Key proposal to include Usage Guide text.

Download Latest Revision
Public Download Link

Submitter: Mr. Kelley Burgin
Group
: OASIS Key Management Interoperability Protocol (KMIP) TC
Folder
: Drafts
Date submitted
: 2013-04-16 03:42:00





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]