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

[Tim Hudson <tjh@cryptsoft.com>]

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.