kmip-interop-tech — archive

[Tim Hudson]

On 6/09/2012 5:01 AM, Bruce Rich wrote: Yeah, what he said. And I would note that immutable does not appear in the spec, so asserting that it's an essential property of KMIP Managed Objects is difficult to agree to.  I agree that Managed Cryptographic Objects do not currently have mutators (if one asserts that Attributes are not part of the objects).  I believe that's merely an observation, not a specification of anything. Ahh ... you missed out on many a debate around exactly this topic back when AlanF was working through how to add Users to the system and how you could go about doing things like changing the password of a User. That made everything attributes in the model as an Object is immutable currently as we have explicitly defined no operations that would support updating the value or included any concept anywhere in the specification that would even hint that such a concept is meant to be possible. Given some of the arguments about what is permitted in the past have been entirely based on well it doesn't say you can so obviously you cannot I think we have established the mechanism for determining the intent given it wasn't captured during the production of the document :-) Of course you can add/modify/delete attributes - but those are the attributes of the managed object itself - like every other managed object. They have nothing to do with the attributes contained within the template structure. And yes I do see that the specification allows you to intermix template and object attributes in the Template structure which creates a level of mess - and I continue to argue that it was a mistake to allow that and it should be fixed. However it doesn't mean that we should suggest that the rules for how a template is handled and its lifecycle should be different to all other objects in the system without some serious consideration to the implications. You cannot just crisp up Get for Templates - basically Section 2.2.6 needs to be rewritten as it is ambiguous and then you need to define what attributes are subject to Add/Modify/Delete if you see the collection of attributes as one pool of attributes some of which are for the object and some of which are for applying to other objects. Nothing related to fixing this is a simply crisping up. Tim.