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: 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

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