kmip-interop-tech — archive

[Mathias Bjorkqvist]

All,


Here are my summary notes from today's interop call. Please let me know
of any additions/corrections you might have.


Regards,

Mathias



KMIP interop call 2010-09-16
Attending: Tim, Bruce, Alan, Stan, Mathias

Two comments from Tim related to the
Digest attribute: 1) the Digest attribute is not exercised in use cases;
and 2) it is not clear if the client can request individual fields from
an attribute, e.g., do a Get Attributes for the attribute "Digest
Value" and just get this field. Section 3, 3rd paragraph in the spec
says "The first table in each subsection contains the attribute name
in the first row.", e.g., "Unique Identifier", but nothing
is said one way or the other about subsequent rows, i.e. if "Digest
Value" is an attribute and/or if it can be operated on in Modify Attribute,
Get Attribute etc operations. There is a list of attributes in Appendix
A, which is non normative and does not mention custom attributes. The interpretation
by most seems to be that subfields are not attributes and operations on
them are not possible.


Question from Tim whether or not the
server is required to return e.g. the Usage Limits Count field when a client
performs an Add Attribute where only the Usage Limits Unit and Usage Limits
Total are specified (the server is required to create the Usage Limits
Count field when the attribute is added/created). Currently the CryptSoft
server does not return the Count field in the Usage Limits attribute but
the IBM server does. From a Result Status of Success, the client can assume
that the field was successfully filled in, and therefore the functionality
of having the created attribute returned is not needed at all. Bruce pointed
out that returning the created attribute is an artifact from the time when
the server was allowed to "mutate" or change the attribute values
that the client requested if the server policy requires it. According to
the current spec this is no longer possible for the server, but the attribute
was not removed from the response payload since we planned to review the
possibility for the server to mutate values in upcoming KMIP versions.
Mathias added that for the Application Specific Information attribute,
 the client can leave out the Application Data field and have the
server generate the value based on the specified Application Namespace
field. In this case it makes sense to require the server return the new
Attribute in the response payload. Suggest that this be clarified in the
spec.


To dos: Clarify the aforementioned items
in the spec and possibly in the other documents where needed. Add a use
case for the (mandatory) Digest attribute.