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

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

Thank you, Tim.

My mention of the 'Extension Information's ambiguity stems from my desire to improve the KMIP specification -- not from an inability to implement the specification. 

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.

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. I believe this oversight ought to be corrected [or the intent to be vague (and its advantage) should be explained].

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.

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 4:15 AM
To: kmip@lists.oasis-open.org
Subject: Re: [kmip] Query Operation: Extension Information is ambiguous

On 20/10/2015 7:08 AM, Featherstone, David wrote:
> 1.       Although an *Extension Map* is quite different from an
> *Extension List*, in both cases the containing Structure tag is 
> *Extension Information*. One tag for two different data 
> representations necessitates tedious look-ahead logic in the parsing code.

Conceptually the only difference between the two is the level of information being provided in the result - it is conceptually the same concept - one is asking just for names and the other for the full details - basically a terse and a verbose response - which is one of the reasons why the result structure is the same - as they are both information about extensions.

It is also not actually ambiguous - and the same tag is used in multiple contexts in multiple parts of KMIP in many messages - and you do have to be aware of the context. It isn't an issue of the tag requiring different interpretation - it is the same tag with exactly the same meaning and same interpretation.

Putting this another way, this is simply a representation of a structure which has variant (optional) fields - it is the same structure - just two of the fields may not be present - i.e. those two fields are optional.
There are
many such structures within KMIP where fields are optional - and different in different contexts - take a look at the structures in use within Key Block, Key Value and Key Wrapping Data. KMIP also uses (as another example) the Attribute Name as a field both inside and outside of the enclosing Attribute Structure.

I don't know of any other vendor that has so far expressed this as an issue - it would be interesting to see if those many others who successfully implemented this long ago saw this as an issue or not. I know from our perspective this wasn't an issue across four client SDKs and two server SDKs so clearly our parsing approach differs from what you are taking if this is causing you a significant problem.

>
> 3.       In the *Extension Map* data representation, the *Extension
> Type* element has been assigned the *Integer*type. So, a map whose 
> *Extension Type* is *Text String* (*7*) would be communicated as:
>
> <ExtensionType type="*Integer*" value="*7*"/>
>
> The above information would be better communicated if *Extension Type* 
> were an *Enumeration*:
>
>  <ExtensionType type="*Enumeration*" value="*TextString*"/>
>

This was discussed at the time but as the Item Type values from 9.1.1.2 are not an enumeration the byte values noted there were directly used as they are logically single byte values within the specification and not enumerations. If they had been encoded as an enumeration then it would be logical (for a user) to assume the value range was much greater than a single byte value. So it was discussed and we went with integer.

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.