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: [kmip] RE: pros and cons for get_attribute alternatives


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

-- John

From: Jon Geater [mailto:Jon.Geater@thales-esecurity.com]
Sent: Tuesday, 12 July 2011 2:45 AM
To: jl@quintessencelabs.com
Cc: kmip@lists.oasis-open.org
Subject: RE: [kmip] RE: pros and cons for get_attribute alternatives

 

Hi John,

My reading of option 2 doesn’t say that the request is invalid, it’s just not optimally formed.

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.

Jon

From: John Leiseboer [mailto:jleiseboer@bigpond.com]
Sent: 11 July 2011 14:15
To: Jon Geater
Cc: robert.griffin@rsa.com; kmip@lists.oasis-open.org
Subject: RE: [kmip] RE: pros and cons for get_attribute alternatives

 

Option 2 (server must return only a single answer for each attribute, even if repeated) might set a precedent that could lead to difficulties if applied to future request-response messages. Option 2 effectively says that the client request is invalid, and that the server will change the invalid request into one that it deems is valid. In my opinion, if it is invalid for a client to request the same attribute multiple times, then the response should be an error response. The server should not be permitted to “correct” the request and return what it deems is the right answer to the wrong question.

As I commented in the poll when I voted for option 3 (server must return an answer for each attribute in the request, including repeated attributes) other protocols and applications respond to repeated attributes in a request with repeated attribute values in the response (e.g. SQL SELECT and SNMP GetRequest-PDU). Unless there is good reason to believe that SQL and SNMP (and others) have got it wrong, we might be wise to follow their example. It should not be the server’s task to determine why a client has asked for repeated attributes. It should simply be the server’s task to respond to clients’ requests.

-- John

From: Jon Geater [mailto:Jon.Geater@thales-esecurity.com]
Sent: Monday, 11 July 2011 9:30 PM
To: robert.griffin@rsa.com; kmip@lists.oasis-open.org
Subject: [kmip] 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!

Jon

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

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

 

 

 


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.

 


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]