Re: [kmip] Groups - kmip-spec-v2.0-wd03-MulitpleIdPlaceholders.pdf uploaded

I for one donât like an attribute, as important as unique identifier, having multiple possible types.   I think it increases complexity too much.    Rather have a set of different attributes.  I think different set of attributes would make it easier for customers to handle 

Best,
Mark Joseph

P6R,  Inc

408-205-0361



On Aug 20, 2018, at 7:35 AM, White, Charles <> wrote:

The question we need to ask ourselves is how much is this likely to change over time, and are we setting ourselves up for failure by inadvertently overloading an attribute.

Also we will need to consider for each of the places where it is called out â which variant of it are we talking about. I believe that Tony and I need to review the places where the Linked Object Identifier shows
 up and see if there is enough specificity in place to allow for polymorphism of the attribute.

If it comes down to it that the operations that use Linked Object Identifier cannot differentiate based on the command â then we have another challenge from an interoperability perspective. We might want to create
 a new attribute to represent circumstances where the operation cannot provide enough specificity to differentiate between one version or another.

Another option is to say Text String â sigh, and move onto to other issues. I donât think that is the right answer â but it is the lesser of two evils compared to fuzzy interpretation of what a Link Object Identifier
 âcouldâ be vs what it âisâ. 

I hope after a review on this we find we can specify the type of Link Object Identifier being used, and map it intelligently to the affected profiles and test cases for conformance purposes.

Thanks!

 

Chuck

 

From:  [mailto:]
On Behalf Of Tony Cox

Sent: Monday, August 20, 2018 2:16 AM

To: 

Subject: Re: [kmip] Groups - kmip-spec-v2.0-wd03-MulitpleIdPlaceholders.pdf uploaded

 

Pending a discussion with Chuck when timezones align, my preference would be simply to amend Table 122 in 4.49 Unique Identifer. Given the relatively few (only) instances where it is called out as a Text String - a change here has least overall impact. I'd
 suggest the following:

"Text String" becomes "Text String or Enumeration or Integer"

Cheers,

-Tony

On 20-Aug-18 7:59 AM, Tim Hudson wrote:

Yes it does change and how to show that is a challenge I guess.

 

We have variable type things in KeyValue/KeyMaterial handling already but this one hits lots more places in the specification.

 

Perhaps Variable with a cross reference to the place where we describe it?

 

Tony/Chuck any editor views on how to do this?

 

Tim 

 

On Mon, 20 Aug. 2018, 4:57 am Bruce Rich, <> wrote:

Tim, 

 

In this proposal, doesn't the Encoding of Unique Identifier morph from just Text String into a "union" of Text String, Enumeration and Integer?  It's now something other than Text String, but
 I'm not sure how to represent it in a implementation-language-independent fashion...

 

Bruce

 

On Thu, Jul 12, 2018 at 1:18 AM, Tim Hudson <> wrote:

Document Name:

kmip-spec-v2.0-wd03-MulitpleIdPlaceholders.pdf

No description provided.

Download Latest Revision

Public Download Link

Submitter: Tim Hudson

Group: OASIS Key Management Interoperability Protocol (KMIP) TC

Folder: Drafts

Date submitted: 2018-07-11 22:18:11