[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [kmip] KMIP Conformance Decision Tree
Matt,
I concur with your Editorial Comments and support the
PKCS#11 analogy.
The base KMIP Conformance Profile should specify essential
communications/messaging, plus profile negotiation and/or query and capability
disclosure.
All important usage domains (p1619.3 etc) would develop
their own additional/optional Conformance Profiles.
Regards,
Steve Wierenga
HP From: Matthew.Ball@Sun.COM [mailto:Matthew.Ball@Sun.COM] Sent: Wednesday, August 26, 2009 10:33 AM To: kmip@lists.oasis-open.org Subject: [kmip] KMIP Conformance Decision Tree In looking at recent reflector discussion on conformance, I think we've reached a saturation of data and opinions, and need to distill this down to a set of simple decisions for the TC to make to move this issue forward. This e-mail is an attempt at this. Please feel free to fine tune it. As I've said before, we need to make sure to meet the requirements within the OASIS Conformance Guidelines. Open questions:
[Matt's Editorial Comments:] In reading the OASIS Conformance Guildelines, there are a couple notes:
This model follows that of PKCS#11 fairly closely. To claim compliance as a PKCS#11 provider, it's only necessary to implement a small subset of all PKCS#11 commands -- essentially the commands that allow the application to query the capabilities of the PKCS#11 provider. Even so, most PKCS#11 providers still typically provide an extensive set of algorithms and in general have good interoperability. Cheers, -Matt |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]