Re: [kmip] Error in kmip-spec-v2.0-csd01 for Locate operation

[Tim Hudson <tjh@cryptsoft.com>]

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