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

Sent: Thursday, June 11, 2009 8:52 AM
To: Rod 
Wideman
Cc: 
Subject: Re: [kmip] 
Support for repeated fields and multiple attribute instances 
determination?

Rod, 

"Rod Wideman" <> 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? 

Regards, 
-Robert 

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.