OASIS Open Mailing List Archives  ·  All Lists  ·  kmip-interop-tech  ·  2012-09

kmip-interop-tech — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

Re: KMIP templates


I'm not a voting member of the group, but I agree with Bruce Rich's reasoning that a Get on a Template should add something useful, and I agree with Tim Hudson's reasoning that it can be thought of in terms of returning the value of the object. What I thought confusing initially was that some attributes of the template contribute to a created object and some do not, but I do like that there is just one set of Add/Modify/Delete attribute operations, and *not* separate operations to edit the template attributes that contribute . But really, the only attribute that could get confusing is Name, because the other attributes of the template itself cannot even be specified on the Register (well, other than Object Type) -- e.g. Unique Identifier, Initial Date, etc. But what Tim wrote here now has me looking at the text in the spec for Register differently: Is it the case that the Name attribute of a template passed in Register should be in the Template Attribute, and *not* in the Template, and that, for example, Cryptographic Length *must* be in the Template and not in the Template Attribute (for Register)? I was under the impression that Register worked just like Create, and you could in fact register a template, referring to other templates, and mixing in new attributes (such as Cryptographic Length.) If in the Register of a Template, the Name must be carried external to the Template, i.e. in the Template Attribute of that Request Payload, and all contributing attributes *must* be in the Template object itself (of the Register's Request Payload), then Tim's description of Get of a Template using value makes perfect sense to me. And if, rather, the Template Attribute of the Register's Request Payload can itself amend the Template, and provide additional attributes to the Template being registered (for example, the Template Attribute can contribute Cryptographic Length), that to me seems more of editing the value of the Template and so the idea of the value of the template still makes sense. Two questions I have are: * SHALL the Name attribute of the Template be passed in the Template Attribute of the Register Request Payload, rather than the Template itself? * SHALL the attributes of the Template that contribute to created objects (later, in subsequent operations) be passed in the Template object of the Register's Request Payload, OR, can they also be specified in the Template Attribute? (I prefer the latter to be consistent with Create.) Jim Flood On 9/4/2012 12:59 PM, Tim Hudson wrote: On 5/09/2012 4:25 AM, Bruce Rich wrote: 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 I still think you are basically not resolving the confusion with that approach. Get should return something from Section 2.2 of the specification and in fact if you read it that is what it currently states. This operation requests that the server returns the Managed Object specified by its Unique Identifier . And what is Section 2.2 - Managed Object . That is about as well defined as you can get in terms of the specification. Get should not be interpreting parts of a Managed Object to return or handling anything on an object type specific basis. Where the confusion exists is that you provide attributes in the Template when registering and attributes in the template attribute list and only the attributes in the Template (the managed object) itself should be returned. The whole area of mess is actually in section 2.2.6 and not elsewhere. Whatever a user places in the Template managed object in the Register is what SHALL be returned by the Get. That is clear, simple, and what the current specification states. The specification is unclear on what you are meant to do with attributes provided in the template attribute list in a Register and whether or not it is reasonable to include attributes for the template as distinct from attributes that the template provides to objects that reference it in the template itself. That's what we need to sort out. Tim.

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]