First stab at a conformance profile

Dear TC,

I took a pass at trying to take the
Proof-Of-Concept and represent it as a conformance profile.  You should
find this in the KMIP document repository as Conformance_Clause_Proposal_V3_POC_Profile_V1.pdf

I thought I'd be presenting a simpler
profile than the POC profile, but before I propose a simpler profile, I'd
like to see if it's even possible to take the conformance proposal as it
currently stands and see how one would express the POC.

This way, people can see the conformance
implications of something that's at least vaguely familiar before I venture
into something more controversial.

Although you can read the document and
see comments inserted at various spots, the summary is that I found I had
several problems:

1) The difference between NOT SUPPORTED
and OPTIONAL is vague, at least in my head.  I seem to be doing a
mental coin toss every time I try to decide which flavor of (!(REQUIRED))
I want.  This may be a personal problem, or might be a conformance
proposal problem.  I think it's the latter (but that may be another
symptom of my personal problem :-).

2) The conformance profile is still
too coarse-grained.  I think we need visibility into the enumerations
on what types are supported by implementations.  For example it's
too coarse-grained to say I support Derive Key or I don't.  I could
have an implementation that supported only HASH-derived keys, and not the
other types of key derivation.  The conformance profile should allow
this kind of expressiveness.

3) I really don't understand the client
conformance column.  If the client doesn't make requests of particular
types, then it is not going to have to handle the responses that deal with
those particular types.  It almost seems that the client column is
a requester library and not an actor in the scenario.

 

Bruce A Rich

brich at-sign us dot ibm dot com