OASIS Key Management Interoperability Protocol (KMIP) TC

Section 6.1.27 of kmip-spec-v2.0-csd01, third paragraph, states: "If no attribute is specified in the request, any object SHALL be deemed to match the Locate request." Table 230 lists the Attributes item as REQUIRED in the Request Payload. This contradicts the text in the third paragraph which infers that the Attributes item is OPTIONAL. John John Leiseboer Chief Technology Officer QuintessenceLabs W: quintessencelabs.com E: jl@quintessencelabs.com M(AU): +61 409 487 510 M(US): +1 202 294 6825 Skype: jleiseboer AU: 15 Denison St Deakin ACT 2601 T: +61 2 6260 4922 US: Suite 220 175 Bernal Road San Jose CA 95119 T: +1 650 870 9920

Hi John, The intent of the spec (based on my understanding when implementing the deltas) is that you are required to include the Attributes structure in a Locate operation. There is no corresponding requirement that says the Attributes structure must be populated. This is an intentional construct to signal that a locate request is being provided with no search parameters, and is differentiated from a poorly formed request which fails to include the Attributes structure. In short: Attributes contains the list of zero or more attributes. The list container must be present. The list itself can be empty. Cheers, 2017-02-24T20:38:00Z 1 19 191 1 1 209 14.00 X-NONE X-NONE MicrosoftInternetExplorer4 Tony Cox VP Partners, Alliances & Standards Cryptsoft P: +61 7 3103 0321, US: +1 (650) 918 4307 tony.cox@cryptsoft.com On 12/02/2019 12:29 pm, John Leiseboer wrote: Section 6.1.27 of kmip-spec-v2.0-csd01, third paragraph, states: If no attribute is specified in the request, any object SHALL be deemed to match the Locate request. Table 230 lists the Attributes item as REQUIRED in the Request Payload. This contradicts the text in the third paragraph which infers that the Attributes item is OPTIONAL. John John Leiseboer Chief Technology Officer QuintessenceLabs W: quintessencelabs.com E: jl@quintessencelabs.com M(AU): +61 409 487 510 M(US): +1 202 294 6825 Skype: jleiseboer AU: 15 Denison St Deakin ACT 2601 T: +61 2 6260 4922 US: Suite 220 175 Bernal Road San Jose CA 95119 T: +1 650 870 9920 --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Thanks Tony,
That makes sense and matches the info I posted in my follow-up email. On my first read of the spec this was unclear (and on subsequent reads, I d argue that the spec is a bit ambiguous).
I think that the spec would benefit from some clarity around this.
I d also be interested in hearing what people think about making the attributes structure optional. Missing or empty would have the same meaning.
John




From: kmip@lists.oasis-open.org <kmip@lists.oasis-open.org>
On Behalf Of Tony Cox
Sent: Tuesday, 12 February 2019 3:34 PM
To: kmip@lists.oasis-open.org
Subject: Re: [kmip] Error in kmip-spec-v2.0-csd01 for Locate operation


 
Hi John,
The intent of the spec (based on my understanding when implementing the deltas) is that you are required to include the "Attributes" structure in a Locate operation. There is no corresponding requirement that says the Attributes structure must be populated.
This is an intentional construct to signal that a locate request is being provided with no search parameters, and is differentiated from a poorly formed request which fails to include the Attributes structure.
In short:
Attributes contains the list of zero or more attributes.
The list container must be present. The list itself can be empty.
Cheers,


Tony Cox

VP Partners, Alliances & Standards

Cryptsoft

P:  +61 7 3103 0321, US:  +1 (650) 918 4307
tony.cox@cryptsoft.com



On 12/02/2019 12:29 pm, John Leiseboer wrote:


Section 6.1.27 of kmip-spec-v2.0-csd01, third paragraph, states: "If no attribute is specified in the request, any object SHALL be deemed to match the Locate request."
 
Table 230 lists the Attributes item as REQUIRED in the Request Payload. This contradicts the text in the third paragraph which infers that the Attributes item is OPTIONAL.
 
John
 
John Leiseboer Chief Technology Officer QuintessenceLabs W: quintessencelabs.com
E: jl@quintessencelabs.com M(AU): +61 409 487 510 M(US): +1 202 294 6825 Skype: jleiseboer
AU: 15 Denison St Deakin ACT 2601 T: +61 2 6260 4922
US: Suite 220 175 Bernal Road San Jose CA 95119 T: +1 650 870 9920
 
 
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
 



______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service for QuintessenceLabs Pty Ltd.
______________________________________________________________________

The requirement to have a container for the list makes things consistent with the other uses of lists of attributes within KMIP (although there may still be some exceptions to that which we should look at adjusting). We discussed this during the face to face for the KMIP 2.0 changes - basically KMIP 2.0 is the first opportunity to make those sorts of changes. It didn't happen by accident - it was a deliberate choice to have lists of things have the list container explicitly present in the encoding. The challenge in your reading is there is an Attributes structure (the list) and Attribute structure (for a vendor specific attribute) and attributes in general. Each is a different thing and are logically names - you just have to read the specification keeping in mind what it actually states rather than reading in a different interpretation to what is actually written. The test cases within the profiles document make things exceedingly clear to anyone that is having problems with following the specification text and keeping track of (mentally) the context when reading the prose. Tim. On Tue, Feb 12, 2019 at 4:02 PM John Leiseboer < JL@quintessencelabs.com > wrote: Thanks Tony, That makes sense and matches the info I posted in my follow-up email. On my first read of the spec this was unclear (and on subsequent reads, I d argue that the spec is a bit ambiguous). I think that the spec would benefit from some clarity around this. I d also be interested in hearing what people think about making the attributes structure optional. Missing or empty would have the same meaning. John From: kmip@lists.oasis-open.org < kmip@lists.oasis-open.org > On Behalf Of Tony Cox Sent: Tuesday, 12 February 2019 3:34 PM To: kmip@lists.oasis-open.org Subject: Re: [kmip] Error in kmip-spec-v2.0-csd01 for Locate operation Hi John, The intent of the spec (based on my understanding when implementing the deltas) is that you are required to include the "Attributes" structure in a Locate operation. There is no corresponding requirement that says the Attributes structure must be populated. This is an intentional construct to signal that a locate request is being provided with no search parameters, and is differentiated from a poorly formed request which fails to include the Attributes structure. In short: Attributes contains the list of zero or more attributes. The list container must be present. The list itself can be empty. Cheers, Tony Cox VP Partners, Alliances & Standards Cryptsoft P: +61 7 3103 0321, US: +1 (650) 918 4307 tony.cox@cryptsoft.com On 12/02/2019 12:29 pm, John Leiseboer wrote: Section 6.1.27 of kmip-spec-v2.0-csd01, third paragraph, states: "If no attribute is specified in the request, any object SHALL be deemed to match the Locate request." Table 230 lists the Attributes item as REQUIRED in the Request Payload. This contradicts the text in the third paragraph which infers that the Attributes item is OPTIONAL. John John Leiseboer Chief Technology Officer QuintessenceLabs W: quintessencelabs.com E: jl@quintessencelabs.com M(AU): +61 409 487 510 M(US): +1 202 294 6825 Skype: jleiseboer AU: 15 Denison St Deakin ACT 2601 T: +61 2 6260 4922 US: Suite 220 175 Bernal Road San Jose CA 95119 T: +1 650 870 9920 --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service for QuintessenceLabs Pty Ltd. ______________________________________________________________________