Re: [kmip] RE: pros and cons for get_attribute alternatives

[Tim Hudson <tjh@cryptsoft.com>]

> Unless there is good reason to believe that SQL and SNMP (and others) have got
it wrong, we might be wise to follow their example.

KMIP isn't modelled off SQL or SNMP - and if the TC had applied that approach to
other areas of KMIP then the specification would be different in a whole pile of
areas. Changing the criteria on how to evaluate proposals at this late state
isn't something which should be done lightly.

Although there are many areas of KMIP which I feel that things should have been
done differently, I think consistency with what has been put in place so far is
actually the more important criteria. If there is an existing mechanism or
approach within KMIP then it should be what tips the balance in decisions on
approaches IMHO.

The general approach in KMIP is that the server is where policy decisions are
made and the server has the opportunity to do things which the client did not
request. That isn't the case in SQL or SNMP - the client is specifying precisely
what it wants returned and there is a specified order in the request response.

A rather simple example: the server can add in a whole range of additional
attributes and can return them in a register or create request (or not as it
deems appropriate). The server is not required to create extra attributes. It is
not required to return them it if created them.

e.g. if the client requests a new key with attributes A and B

the server can return any of the following

1) request fails for whatever reason
2) request succeeds and here is the unique identifier
3) request succeeds and here is the unique identifier and attributes C and D
that the server felt like creating

Note: you can argue that the specification meant to state that if attributes are
implicitly created then they must be returned - but that isn't what the
specification states and isn't what (most) of the current implementations
actually do.

An SQL statement where the server can return extra columns in the result set
would be a rather unusual SQL statement :-)

I agree that we should look at other protocols and take into consideration the
approaches there - but not if that means introducing concepts which don't fit
within the approaches already taken by KMIP.

When talking with others I had made what turns out to be an invalid assumption.
I thought that we were in consensus that the answer should be well defined and
not left open to interpretation. Perhaps the proposal should have been handled
in two parts - first well defined, and then the definition of the behaviour.

At the moment as the server rejecting the request is within the list of
permitted behaviours an interoperable client cannot safely send a request with
an attribute name repeated which effectively specifies behaviour 1 as the
de-facto behaviour.

Tim.