Re: [kmip] Query Operation: Extension Information is ambiguous

[Tim Hudson <tjh@cryptsoft.com>]

On 20/10/2015 7:52 PM, Featherstone, David wrote:
> An ExtensionList structure is not merely an ExtensionMap structure with optional ExtensionTag and ExtensionType elements. In an ExtensionList structure, the presence of the ExtensionTag or ExtensionType elements is illegal. In an ExtensionMap structure, the absence of the ExtensionTag and ExtensionType elements is illegal.

There is no ExtensionList structure. There is no ExtensionMap structure.
There is only an ExtensionInformation structure.
You may want to have two other structures but that isn't what is in the
specification and your email is about basically introducing two separate
structures - one with a single field and one with three fields - with
the rationale that it should be changed because it "necessitates tedious
look-ahead logic in the parsing code". That's not our experience and I'm
waiting to see if other implementers have found this an issue and
haven't previously raised it.

The ExtensionInformation structure explicitly notes two fields as
optional within the structure. That is the data contract.
There are many structures within KMIP that have optional fields and
which fields make sense are dependent on the context.

In the context of the usage of that structure for the return type of a
Query operation there are different requirements.

> The KMIP specification is rarely vague about the expected order of appearance of the elements comprising a given KMIP message, and never intentionally vague. In this case, however, the specification allows for the appearance of two distinct structure sequences, yet does not specify their expected order. 

The order of items returned in the Query response is well defined and
fixed.
And if ExtensionMap is in the Query Function list then
ExtensionInformation with all three fields is returned.
There isn't two distinct structures - there is one - and it is
ExtensionInformation.

And it makes little logical sense to return two repeated sets of items
one of which contains a repeat of all the information from the first -
so if the Query Function is for Extension Map then the full three field
structure is returned. There aren't two lists. There isn't an order
issue. And even if there was a return of ExtensionInformation with one
field and one with three fields the order returned inside the
ExtensionList item wouldn't actually matter - what is specified in the
order in which each of the different types of structures (or
enumerations) is returned - not the order within the repeated returned
items.

> In regard to the ExtensionType element, the KMIP 1.2 specification directly references Table 249, which "enumerates" the 10 possible types supported within a KMIP PDU. I do not see that these are "single byte values" rather than enumerations.

Quoting directly from 9.1.1.2 which is where Table 249 is contained and
this is the text just above that table:

"An Item Type *is a byte* containing a coded value that indicates the
data type of the data object. The allowed values are:"

We could have defined an enumeration to cover the equivalent of those
byte values - but we didn't.

Thanks,
Tim.