kmip-interop-tech — archive

[Tim Hudson]

As part of the process of testing we have hit a situation where a wider interpretation of intent is needed. I've labelled the questions so responses can be clearer (hopefully). Some context: 1) a client registers a managed object under KMIP 1.1 2) a client then requests the list of attributes for that object under KMIP 1.0 a) Should attributes which are only defined for KMIP 1.1 (e.g. Fresh) be returned in the request in step 2? The other context of interest is to consider the various vendor defined attributes and extensions which can be set which expand over time. How should those be handled? b) Should they be treated consistently with whatever the view on the first question is? A (good) example is a server supporting KMIP 1.1 that creates the Fresh attribute for objects added to groups - the server will naturally enough create those extra attributes for all objects. c) should it filter the attributes returned for KMIP 1.0 clients pretending that those attributes don't exist? d) should it refuse to return the value of "Fresh" if asked for it by a KMIP 1.0 client even though it exists? And given we now have stuttering clients must be returned an error (as of KMIP 1.1) ... e) should the same apply (i.e. the server return an error) to a client asking for attributes which were defined in a later version of the specification? Tim.