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

["John Leiseboer" <jleiseboer@bigpond.com>]

> 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.
I've never suggested that KMIP is like SQL or SNMP. For that matter, SQL
is not like SNMP, and SNMP is not like SQL either. My references to SQL
and SNMP were simply to illustrate that *other* protocols (different to
KMIP, and different to each other) specify that the response to a
request for repeated items, returns repeated items. This is pretty much
normal behaviour for protocols that *allow* repeated items in requests.
(Makes sense doesn't it? - If you're allowed to repeat a requested item,
you get a response for each repeated item. It doesn't feel right to
allow repeated item requests, but then ignore the additional requests by
requiring that only a single item response be returned.)

I have always been uneasy with option 2 because it seems to me that the
server is not actually returning what the client has asked for. Option 2
appears to require that the server either "correct" an incorrectly
formed request, or "optimise" the response to a poorly formed request.
Surely the protocol should specify whether the request is valid or not,
and specify that the response addresses the request, or returns an
error, respectively?

> 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.
I'm not sure what your point is here. Are you referring to the standard,
to implementations of the standard, or something else? What is the
consistency that you are referring to?

> 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
To be pedantic, option 2 *requires* that the server *not do* something
that the client *did* request. This is quite different to the server
having the opportunity to *do* things that the client *did not* request
due to policy settings.
...
> 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
This poll is about clarifying how the server should respond to repeated
attributes. The standard is unclear with respect to repeated attributes.
Different server implementations have done things differently. I don't
see any connection with server policy for this particular case. Wouldn't
option 4 (leave it [the behaviour] unspecified) better fit the argument
that server policy dictates how to respond?

> 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.
How does option 3 not fit with approaches already taken by KMIP?

> 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.
I think option 1 makes more sense than option 2. But I think option 3 is
better. :-)

-- John