Re: [kmip] Get Attributes

[Tim Hudson <tjh@cryptsoft.com>]

On 13/05/2011 9:07 AM, Lockhart, Robert wrote:
> This is one of those that seems it would be best handled by profiles as different use cases may require specific return results based on a given use case or a specific attribute type.  As part of a profile that makes use of repeated attributes there should be some form of guidelines for creating profiles that dictates how the profile must be set up for each attribute that can be repeated more than once as some use cases may have two or more repeated attribute fields so that each needs specific guidance (ugly use case potentially but should be possible).

I think you'll find that if you want to have multiple different answers returned
in a single request for a given attribute value then this is more appropriately
handled by having multiple batch items.

The semantics of what order the request items should be returned in and how to
determine which item 'value' is the most 'current' would need to be defined and
that's a direction we haven't as yet taken for this operations.

I think repeating the responses which are the same has no value; returning
multiple would require definition of how to match the values up in terms of
their context.

Definitions of how to handle things in an atomic manner in KMIP in general would
also need to be documented.

I wasn't trying to open up that broader discussion - just to get a clarification
on expected behaviour in this area - as it is important for interoperability we
know what to expect - be it option 1,2 or 3 or simple any of the options a
server decides to implement. It impacts how clients need to generate requests
when there are variations.

If it is okay for a server to pick any of the responses then a client for
interoperability needs to never send more than one instance of any attribute in
the request or the response from a server is 'undefined' (error, 1 answer, 2
answers possibly the same, possibly different).

Tim.