OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: pros and cons for get_attribute alternatives

Freely commenting below…let’s see if I’ve missed something.

Firstly, Under what circumstances (other than bugs, race conditions etc) would the value returned for multiple copies of the same attribute be different?  It seems to me that no matter how many times you ask for an attribute in a single call the value returned for all copies should be the same*.  If it isn’t then it’s not the same attribute.  To look at it from the other side, if there are multiple valid values for the exact same attribute then what happens if a request only asks for it once?  Which one does the server choose to return?  The possibility that multiple attribute values represent complexity within an object suggests to me that the object wants to express its complexity clearly, using distinguishable attributes.

Second, does the standard promise to return all attributes in a list in the precise order in which they were asked for?  I didn’t think so, and as we go deeper into language bindings this will get less and less likely (although we could always preserve things at the protocol TTLV level I suppose).

With those in mind, I think the best option is option 2.  It’s nice to allow repeated attributes in the request because it means that templates or similar tables of associated attributes can be simply lumped together in the client implementation without the client having to do any hard deduplication work.  However there’s little added value to returning multiple copies of identical answers because when the client receives the answers it will have to process them anyway.  The potential benefit of multiple answers might have been to copy the blocks of answers straight back into those template structures but that only works if precise mapping and ordering are preserved.  I guess the multiple answers could count as a kind of redundancy check/count but that’s stretching things.

* Please, whoever’s sitting there now dreaming up the pathological “how many times has this attribute been queried?” attribute, stop right there!


From: robert.griffin@rsa.com [mailto:robert.griffin@rsa.com]
Sent: 09 July 2011 08:20
To: kmip@lists.oasis-open.org
Subject: [kmip] pros and cons for get_attribute alternatives


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


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



-    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



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

-    Ensures consistency in attribute value returned.



-    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



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

-    Enables response to reflect complexity in structure of object



-    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


-    Provides greatest flexibility in behavior of server


-    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.





Consider the environment before printing this mail.

Thales e-Security Limited is incorporated in England and Wales with company registration number 2518805. Its registered office is located at 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 2NX.

The information contained in this e-mail is confidential. It may also be privileged. It is intended only for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee or the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error, please inform us immediately on +44 (0)1223 723600 and delete it and all copies from your system. Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of Thales e-Security Limited.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]