Defining specific profile requirements for servers and clients

All,

At the last meeting it was stated that to be KMIP compliant a server does not have to make use of an entire profile to be compliant. Since I am in the process of creating the straw man proposal for ability advertisement/negotiation and want to put forward a suggestion that makes this potentially easier by defining three classes of devices (disregarding devices that may make use of more than one description for now).

KMIP Profile Compliant Server	A server that is compliant with all aspects of a publicly available published profile, defined by OASIS or other organizations (e.g. vendor specific profiles that are available in some form or other), that supports all required and optional components of that profile
KMIP Client Specific Server	A server that is built to work with a specific set of clients that supports the KMIP protocol (vendor or device type specific) without requiring a public profile.
KMIP Compliant Client	A client that implements any one message, function or operation supported by a KMIP compliant server and has show interoperability with a KMIP Profile Compliant Server.

This removes almost all of the burden from the clients and places it squarely on server vendors (sorry guys), but this will help the growth of KMIP for devices other than storage which right now is where most of the KMIP development effort is ongoing.

By providing these three classification the servers could advertise which profiles they support and a client can then decide which of the profiles meets its needs if any. This would simplify the implementation of capability advertisement/negotiation by only requiring the clients to ask and the servers to tell. Basically a KMIP Profile Compliant Server would advertise a set of values that correspond to specific profiles as defined in the standard. A KMIP Client Specific Server would advertise a specific vendor server ID (Think IANA assigned EIN numbers since most vendors will have them for network interfaces). A KMIP Client only has to know what each of the values means and if it doesn’t it can throw an error to its managing system.

It keeps the overhead down of having to advertise every message, operation and object that a server supports and the clients having to parse all of it to decide it works or not.

I would really like feedback before I start down this road and any input would be greatly appreciated.

Bob L.

Robert A. (Bob) Lockhart

Senior Solutions Architect

THALES e-Security, Inc.

-------------------------------------------------------

T: +1 408 457 7711 (Direct)

M: +1 510 410 0585

F: +1 408 457 7681

E: Robert.Lockhart@thalesesec.com

W: www.thalesgroup.com/iss

kmip message