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 - 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.





From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Tony Cox
Sent: Monday, August 20, 2018 2:16 AM
To: kmip@lists.oasis-open.org
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"


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?




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



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...




On Thu, Jul 12, 2018 at 1:18 AM, Tim Hudson <tjh@cryptsoft.com> 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



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