OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Application Specific Information conerns


I'd like to echo Indra's earlier concerns regarding a provision in the Application Specific Information proposal.

The provision creates an option for the client to ask the server to set the application specific information for any namespace, and requires the server to return an error if the namespace is not understood.  The namespaces listed are merely examples, however, and no data is given for how the server should set the data for any particular namespace.  A server implementer who follows the specification and usage guide will not know how to set any Application Specific Information values, and therefore will not be interoperable with clients relying on this functionality.  In effect, any arbitrary namespace string is an implicit critical extension to the protocol.

The severity of the impact depends on how the client responds to this error.  A sophisticated client might have enough logic to handle the failure, and send a new request without the App Specific Info request.  A more naive client will simply not interoperate.

A related issue is that different vendors could end up using the same Application Specific namespace with different expectations for how the values should be set, resulting in more interoperability problems.

Wouldn't it be better to leave Application Specific Information to be explicitly set by the client or template values, and define extensions governing how the server should set given namespace-specific information (per section 6.16)?  This has the advantage that clients requiring this functionality for operation can set the criticality indicator to True.  Though not presently defined, extensions could be registered to prevent collisions.  Hopefully vendors will publish their extension specifications so other KMIP servers can serve enhanced clients.

Rene, can you explain the intended use-cases for server-set App Specific Information?  Do you think extensions might be a more interoperable way to address them?

Thanks

-Alan  The information contained in this electronic mail transmission 
may be privileged and confidential, and therefore, protected 
from disclosure. If you have received this communication in 
error, please notify us immediately by replying to this 
message and deleting it from your computer without copying 
or disclosing it.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]