[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [kmip] Query Operation: Extension Information is ambiguous
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]