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

["Featherstone, David" <David.Featherstone@safenet-inc.com>]

Thank you, Tim.

You state: " And it makes little logical sense to return two repeated sets of items ..."

Indeed, a list of extension names to be immediately preceded/followed by those same names in an extension map makes little sense, yet the specification allows for it. The specification could eliminate that nonsensical behavior by changing the text of the Query operation from:

1676       The Extension Information fields in the response contain the descriptions of Objects with Item Tag values
1677       in the Extensions range that are supported by the server (see Section 2.1.9). If the request contains a
1678       Query Extension List
1678                                                   and/or
1678                                                                   Query Extension Map value in the Query Function field, then the Extensions
1679       Information fields SHALL be returned in the response. If the Query Function field contains the Query
1680       Extension Map value, then the Extension Tag and Extension Type fields SHALL be specified in the
1681       Extension Information values.

to:

1676       The Extension Information fields in the response contain the descriptions of Objects with Item Tag values
1677       in the Extensions range that are supported by the server (see Section 2.1.9). If the request contains a
1678       Query Extension List
1678        ****>                                    or
1678                                                                   Query Extension Map value in the Query Function field, then the Extensions
1679       Information fields SHALL be returned in the response. If the Query Function field contains the Query
1680       Extension Map value, then the Extension Tag and Extension Type fields SHALL be specified in the
1681       Extension Information values.
1681       ****>                                                 Only one of Query Extension List or Query Extension Map SHALL be specified.

Cheers,
... Dave

-----Original Message-----
From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Tim Hudson
Sent: Tuesday, October 20, 2015 7:15 AM
To: kmip@lists.oasis-open.org
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.


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


-- 
The information contained in this electronic mail transmission 
may be privileged and confidential, and therefore, protected 
from disclosure. If you have received this communication in 
error, please notify us immediately by replying to this 
message and deleting it from your computer without copying 
or disclosing it.