Tim,
The spec does not use the term "value" in either Register or Get, so I would not want to introduce a new term now. However, the spec does list the attributes applicable to objects created using the Template. So my amended proposal is now
======
snip, snip
===============================
It would seem that since a Template is a Managed Object and NOT a Cryptographic Object, we need to correct the Response Payload for GET in section 4.11 to say that it returns a Managed Object,, not a Cryptographic Object. (Cryptographic Objects are Managed Objects, but the converse is not true.)
Additionally, we would need to add a clause to either Section 2.2.6 or to 4.11, that says:
A GET of a Template SHALL return only the attributes "applicable to objects created using the Template" in section 2.2.6.
If the above text were to be added to section 2.2.6, then we would not need the self-reference, but in any case, it would be helpful to have a link to the exact part of section 2.2.6 where the attributes are enumerated. I would prefer not to have multiple copies of the list to keep in synch.
And this would become testable in the next version of the KMIP spec.
======
snip, snip
===============================
Bruce A Rich brich at-sign us dot ibm dot com
From: Tim Hudson <>
To: Bruce Rich/Austin/IBM@IBMUS
Cc: John Leiseboer <>, "" <>
Date: 09/01/2012 07:37 PM
Subject: Re: [kmip-interop-tech] Re: KMIP templates
On 1/09/2012 1:39 AM, Bruce Rich wrote:
I agree with the SHALL.
As do I - however I think that Get is much better defined as returning the value of the object - which for objects specified via Register that is well defined as what was passed in which was not in the attributes list - i.e. the "value".
That is the one and only logical thing in my view to return - making it entirely consistent with all the other objects in the system. Most of the confusion in the area of templates is the wording used which does not distinguish clearly between attributes of an object and the attributes which just happen to be the value of the object. We also hit confusion when attributes can be associated with wrapped keys so a conversation in the context can make reference to "attributes" rather unclear.
There is similar confusion on specification of the name of the template too which is another topic to cover off on as we work through this.
If we had Get SHALL return the value of the Managed Object as specified in Section 2.2 then I think that is easiest and clearest way to make the result clear (and I would argue well within a reasonable interpretation of the current specification - although not the only interpretation that is possible).
Tim
