From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org]
On Behalf Of White, Charles
Sent: Monday, August 20, 2018 10:35 AM
To: tony.cox@cryptsoft.com; kmip@lists.oasis-open.org
Subject: RE: [kmip] Groups - kmip-spec-v2.0-wd03-MulitpleIdPlaceholders.pdf uploaded
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
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,
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...