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: RE: [kmip] Support for repeated fields and multiple attribute instances determination?

Thanks, Robert.
I wonder if at least some minimum numbers need to be specified, to assure interoperability.  If a client is developed that uses 'n' number of repeated fields/instances on one server, then will it be interoperable on other servers?  A full discovery mechanism could be defined, but specifying minimums would at least provide a 'least common denominator' baseline for compliance.
Rod Wideman
Quantum Corporation
(please disregard the confidentiality statement below)

From: Robert Haas [mailto:rha@zurich.ibm.com]
Sent: Thursday, June 11, 2009 8:52 AM
To: Rod Wideman
Cc: kmip@lists.oasis-open.org
Subject: Re: [kmip] Support for repeated fields and multiple attribute instances determination?


"Rod Wideman" <Rod.Wideman@quantum.com> wrote on 06/11/2009 01:51:57 AM:
> How does a client determine how many instances of repeatable fields
> or multiple attributes are supported by a key server for a given
> object or operation? Presumably different key servers will have
> different limits.

In the editorial changes I proposed last week the following item was included:

"11.2, 11.3, 11.4, 11.14 (Create, Create Key Pair, Register, Add Attribute): Add a new Result Reason of "Index Out of Bounds" if the client tries to set more attribute instances than the server allows."

Note that the client won't know ahead of time what is the maximum number of instances supported for a given attribute by a given server: it is expected to be reasonably large so that such "out of bounds" errors occur only rarely.

In terms of repeatable fields in operation requests and responses, only the maximum size of a response can be set by the client. So far, servers are expected to handle all request sizes. Is this acceptable?


The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum Corporation. Furthermore, Quantum Corporation is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.

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