pros and cons for get_attribute alternatives

[<robert.griffin@rsa.com>]

Hi –

Following the close of the inconclusive ballot on get_attributes, I offered to put together a quick summary of pros and cons for the various alternatives. Here’s a first cut. Please comment freely! Note that there was extensive discussion of this question on the KMIP mailing list during May; please see the email archive for those messages.

The question is what the default behavior should be on a get_attributes request if the request includes repeated values, that is, includes the same attribute multiple times within the same message.

Alternative 1:  server must reject if client repeats an attribute

Pro:

-    As long as the error condition returned is unambiguous, provides the clearest indication of expected construction of request.

 

Con:

-    Requires client to re-construct and re-send request. This could be difficult if the original construction of request represented complexity in object (for example, same attribute expressed in multiple structures within object for purposes of optimization)

 

 

Alternative 2: server must return only a single answer for each attribute

 

Pro:

-    Does not require client to re-construct and re-send request.

-    Ensures consistency in attribute value returned.

 

Con:

-    May not reflect complexity in structure of object, making it difficult for client to get all the information it needs.

 

 

Alternative 3: server must return an answer for each attribute in the request

 

Pro:

-    Does not require client to re-construct and re-send request.

-    Enables response to reflect complexity in structure of object

 

Con:

-    Could result in un-intended ambiguity and complexity in the response.

-    Requires definition of the semantics of what order the request items should be returned in and how to determine which item 'value' is the most 'current'. Also requires consideration of atomicity issues for the response.

-    This kind of complexity could be more effectively handled by including multiple get_attribute requests in a single message, by means of the KMIP batch mechanism

 

 

Alternative 4: leave it unspecified so any of 1-3 are permitted

Pro:

-    Provides greatest flexibility in behavior of server

Con:

-    Ambiguity of response would have to be addressed either through out-of-band convention, through additional attribute (custom or new) or through profile.

 

My thoughts:

It seems to me that this is potentially intentional behavior (rather than an error in construction) reflecting complexity in the definition of the object (that is, the same attribute defined in multiple structures in order to optimize processing of the object).

If we do allow such complexity (Robert, please clarify whether this is indeed the case), then we should probably support that complexity both in the request and the response? If we do not allow such complexity, then we should probably reject the request? In any case, I don’t think we should go with alternative 4.

Regards,

Bob