[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [kmip] Question for today's agenda: ID Placeholder
Hi Tim You are quite correct to say that the KMIP specification defines the behaviour unambiguously – if you know the spec you can predict the outcome – but I suggest that this behaviour is counter-intuitive. It makes more sense that an explicitly specified UID would in turn set the ID Placeholder to that same UID. I can foresee issues with changing the spec in the KMIP 1.X timeframe, but this matter could be considered for KMIP 2.0. W.r.t. ‘Check’, you’re correct – I chose a bad example. W.r.t. ‘Create Split Key’, you misunderstood: Judy Furlong points out that the specification neglects to state that ‘Create Split Key’ [and some other new operations] sets the ID Placeholder. Cheers, … Dave From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Tim Hudson Just checking - do you think the specification is unclear on the behaviour here or not? Get doesn't "set" the ID Placeholder as it is already set by previous operations - either you know the Unique Identifier and provided it and can provide it equivalently in subsequent batch items or you are using the ID Placeholder in the Get itself and it remains unchanged - that is consistent - and that is the class of behaviour you are basically finding strange - it applies across all the operations which aren't constructors or search operations. It isn't hazardous any more than saying someone could put the wrong unique identifier values in batch items and get something other than what they intended - the request is well defined - the outcome is unambiguous. That the Create Split Key operation does not use the ID Placeholder was a deliberate choice at the time. It is a constructor of objects - so it follows the same pattern as the other constructor operations - and even though it can construct based on other objects (just like Derive Key can) it also follows that pattern to not use the ID Placeholder. On Check you need to look at the context - the ID Placeholder is used on Check - but Check itself clears it if the result of the Check would be a failure - deliberately so that it can be combined in a batch and effectively act as a conditional - only if Check passed correctly do the following operations have the required items specified. There is no "leapfrog" going on here Tim. The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]