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

[Tim Hudson <tjh@cryptsoft.com>]

On 12/07/2011 11:03 PM, John Leiseboer wrote:

A55880E5F04A3E489A4E428F5B3D7CAF160791@server.qbrick.local" type="cite">

> With your recommendation below to follow option 3 would you introduce a requirement for all occurrences of a repeated attribute to be identical, would you expect them to be different in some known circumstances or would you leave that up to the server implementation?  My preference for option 2 is that it side-steps this issue so I’m interested to hear opinion on it.

My preference would be for the values of the repeated attributes to be identical. I would prefer to see this as a “SHOULD” statement in the standard. I don’t think this should be a “MUST” or “SHALL”.

If it isn't SHALL be the same value then I think the circumstances under which it can be different and the mechanism whereby the client can meaningfully determine which is the most recent value would need to be well defined.

This seems more than a little inconsistent with the argument around SQL and SNMP stating that it is reasonable to request a value multiple times.
It would be like SQL statements querying columns multiple times getting back different values for a column in a single row something which would be fundamentally wrong (in the SQL context).

I do note your preference for identical but the reluctance to specify this as the required behaviour is what I think needs exploration. This is one of the many areas where the behaviour needs to be well defined for interoperability purposes or will end up with more clients being produced which simply are unable to talk to a range of servers except through trial and error to determine the lowest common denominator of behaviour. Working through that process will give KMIP a bit of a bad reputation in terms of delivering on *interoperability* and to me at least that should be what guides the TC decision making process.

Right now we are at the point where anything other than unspecified (leading to interoperability issues) will require one or more vendors to change their shipping products. It is I think one of the reasons why we didn't reach consensus and why I asked for a ballot to get a wider group opinion which came back with rather mixed results reflecting the diverse TC member background.

I see any area in the specification where vendors have taken a different approach during implementation which impacts interoperability is an area that needs to be addressed in the specification.

Tim.