kmip-interop-tech — archive

[John Leiseboer]

>> a) Should attributes which are only defined for KMIP 1.1 (e.g. Fresh) be >> returned in the request in step 2? >> > > I don't think it makes sense to return Fresh in this case, since a 1.0 > client would not know how to interpret it. One might think of a use case > where an application that is aware of 1.1 attributes talks to the server > using a 1.0 client, in which case the app might want to know of the > Fresh attribute. However, passing the value of the Fresh attribute would > be problematic here, since the 1.0 client does not know what the various > tags mean. I agree - do not return 1.1 attributes in a 1.0 message response >> 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? >> > > I would say this is up to the vendor. Here I would be more ok with > returning all attributes to a 1.0 client, since the client would anyway > need to understand the attribute name in order to interpret it. This > functionality might not be tied to the protocol version. I would qualify this by saying that the server should only return attributes that it knows the client can interpret; i.e. only vendor defined attributes and extensions that the client has explicitly requested. Any attribute that is not explicitly defined in the standard or explicitly requested by the client, should not be returned to a client by default. > Unless we have a central registry that keeps track of when (at which > protocol version) certain vendor-specific attributes were introduced, > I don't see that we can easily regulate the behavior. We could certainly > have guidelines, but I would rather see them as SHOULDs rather than > SHALLs. If we can live with the qualification I gave above, then I think we can have SHALLs. > One might argue that this also applies to the standard attributes. > > >> 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. >> > > I would say that the server, if configured to do so for group management, > may create the Fresh attributes for new objects being created/registered > by 1.0 clients. > Let's hope that we never create new attributes that conflict with existing ones; e.g. by changing the type, or removing allowed values. This also raises the question of what should be done when a server is upgraded and/or data is imported from 1.0 systems. Do objects created in the days of 1.0 suddenly acquire new 1.1 attributes? Is this inside or outside the scope of KMIP? >> c) should it filter the attributes returned for KMIP 1.0 clients >> pretending that those attributes don't exist? > > Yes. I agree, yes. >> d) should it refuse to return the value of "Fresh" if asked for it >> by a KMIP 1.0 client even though it exists? >> > > Yes. I agree, yes. >> 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? >> > > Yes. What error should be returned for an undefined tag? Two currently defined errors that might fit are: "unknown field" or "message cannot be parsed". > Does this issue also apply to operations (e.g. what happens if a 1.0 > client issues a Re-key Key Pair request), or is this already clearly > defined? I'm fairly certain that our interop server responds differently > to the behavior I suggested above :-) Should be consistent with d) above; i.e. refuse to perform the operation. Should check for consistency with Query(Query operations). johnl