Bruce -
OK, I understand what you are saying. However, I
wonder about a standard with no required exchanges for claiming
conformance. There should be something the system must handle to claim
conformance. If you can answer "not supported" to every object and still
say you are conformant, you have delivered nothing of value and that waters down
the claims of truly conformant systems.
- Peter
From: Bruce Rich [mailto:]
Sent: 2009-05-14 8:27 AM
To: Zelechoski,
Peter
Cc: ;
Subject: RE: [kmip] question regarding
conformance statement for KMIP
Peter,
I'm not sure what you meant by "mandatory object".
It would seem that all objects are optional, as the server's response to a
Query Objects operation specifies those objects that the server supports, and
all the managed objects are potential entries in that list. So if a server does
not wish to support registration of SplitKey, then it would simply omit SplitKey
from the list of objects that it claims it will support (if the client bothers
to ask via Query Objects).
Bruce A
Rich
brich at-sign us dot ibm dot com
From:
"Zelechoski, Peter"
<>
To:
<>
Cc:
<>
Date:
05/13/2009 08:57 PM
Subject:
RE: [kmip] question regarding conformance
statement for KMIP
Robert -
My opinion is that an
implementation that wants to claim compliance to
the standard would be
required to respond accurately to all
required/mandatory objects. A
response of "not supported" would only be
appropriate for an optional
object.
- Peter
-----Original Message-----
From:
[mailto:]
Sent:
2009-05-13 7:36 PM
To:
Subject: [kmip] question
regarding conformance statement for KMIP
Hi -
Rather than
convening a meeting on conformance (as I'd suggested a
couple of meetings
ago), I'd like to pose the question I've been
wondering about and see if
there is an issue or not:
-
Should we modify the language in Section 5 of the Usage Guide
to
clarify what "support all objects etc" means? In particular, do we
need
to clarify whether this means a) the server has to implement
all
mandatory objects etc or b) the server has to understand
requests
related to all mandatory objects etc (but can return back an "object
not
supported" message).
In drafting the conformance language
currently included in the Usage
Guide, I followed the advice expressed in the
Conformance Testing
document available at http://xml.coverpages.org/conform20000112.html:
that is, "the requirements or criteria for conformance must be
specified
in the standard or specification. This is usually in a
conformance
clause or conformance statement..."
The conformance
statement in section 5 of the KMIP Usage Guide
distinguishes between
conformance requirements for KMIP servers and
clients:
"Server
implementations of the KMIP protocol must support all objects,
attributes,
operations and profiles not specified as "optional" in the
KMIP Specification
in order to be conformant to the specification.
Server implementations that
do not support objects, attributes,
operations and profiles defined as
"optional" can claim KMIP
conformance, though they may be limited in terms of
interoperability
with other KMIP implementations.
Client
implementations of the KMIP protocol may implement any subset of
the KMIP
protocol. For example, a client may implement only the Get and
Locate
operations for symmetric keys. In order to claim conformance,
however, such a
client must implement all aspects of any elements of the
protocol (objects,
attributes, operations, profiles) that it claims to
support. In the example
of Get/Locate support for symmetric keys,
therefore, a conforming client
implementation must support all required
attributes for symmetric
keys."
In re-reading the conformance statement for server
implementations, it
looks to me that I made it more restrictive than I
intended - that the
language should perhaps have been something
like:
"Server implementations of the KMIP protocol shall accept and
respond to
client requests for all objects, operations and profiles not
specified
as 'optional' in the KMIP Specification in order to be conformant
to the
specification; a conformant response can be 'this object etc is
not
supported.'"
But perhaps it's better to have the more restrictive
language, after
all?
I'd appreciate your
thoughts!
Regards,
Bob
---------------------------------------------------------------------
To
unsubscribe from this mail list, you must leave the OASIS TC that
generates
this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To
unsubscribe from this mail list, you must leave the OASIS TC that
generates
this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
