[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [kmip] Groups - KMIP Server Conformance Proposal (KMIP ServerConformance Proposal.pdf) uploaded
I am still not sure we want to list conformance profiles other than to say one or more with no list instead of zero or more with a list. In theory while I am not sure you would be able to do much,
you could just do the base server requirement and claim conformance and then go off and do what you wanted to reguardless of the standard (seems to defeat the purpose).
This kind of takes me back to allowing external groups the ability ot create profiles as well as the TC creating two or three as guidelines (basic symmetric, basic assymetric & basic server to client). We may also
want to consider defining the big kahuna profile for a server that does it all.
Bob L.
Robert A. (Bob) Lockhart
Senior Solutions Architect THALES Information Systems Security ------------------------------------------------------- T: +1 408 457 7711 (Direct) M: +1 510 410 0585 F: +1 408 457 7681 E: rlockhart@ncipher.com From: Matthew.Ball@Sun.COM [Matthew.Ball@Sun.COM] Sent: Thursday, September 03, 2009 10:24 AM To: Robert Lockhart Cc: kmip@lists.oasis-open.org Subject: Re: [kmip] Groups - KMIP Server Conformance Proposal (KMIP Server Conformance Proposal.pdf) uploaded Hi Bob,
Actually, I'm thinking the conformance text would be something like this: An implementation SHALL be a conforming KMIP Server.In other words, everything is a conforming KMIP Server, but may additionally conform to a particular profile or set of profiles. That said, I would prefer that we leave out profiles entirely from the KMIP specification, but don't see a problem adding a couple profiles in (aside from it pushing out the schedule). I'm hesitant to put 'requirements' on the profiles themselves, though, because this is a bit like 'meta-work' instead of 'real-work'. However, if we make profiles an integral part of the protocol, with a profile registry and ways for clients to retrieve the profile name, then we'll need to be precise in creating ways for the client to find out exactly which algorithms and commands are supported by the KMIP Server. This will probably be a fair bit of work, although I haven't scoped the effort. Cheers, -Matt Robert Lockhart wrote:
The information contained in this e-mail is confidential. It may also be privileged. It is only intended for the stated addressee(s) and access to it by any other person is unauthorized. If you are not an addressee or the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorized use may be unlawful. If you have received this e-mail in error please delete it (and all copies) from your system, please also inform us immediately on +1 (781) 994 4000 or email ussales@thalesesec.com. Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of Thales. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]