Attribute Index re-use

[Mathias Bjoerkqvist1 <MBJ@zurich.ibm.com>]

All,

Currently, Section 2.1.1 in the KMIP specification
says the following:

The Attribute Index of an attribute SHALL NOT change
when other
instances are added or deleted. For example, if a particular attribute
has 4 instances with Attribute Indices 0, 1, 2 and 3, and the instance
with Attribute Index 2 is deleted, then the Attribute Index of instance
3 is not changed.

However, nothing is said about attribute re-use. In
the example above,
if a new attribute instance is added, can it receive
attribute index 2,
or would the next available index value be 4?

Discussion on the interop call today revealed that
we currently have
implementations of both alternatives. Clarifying the
behavior would
be desirable. Suggested behavior or mandatory requirements
(SHOULD,
SHALL) are both possible.

Disallowing index re-use would eventually lead to
overflow of the index
value. This situation could be resolved by allowing
the index to wrap
around, which essentially is a delayed re-use.

Allowing index re-use can lead to confusion for clients.
The fact that
we do allow the index to change for existing instances
indicates that
the original intent was to avoid confusion.

Some questions:

1) Are clients making use of the attribute index in
ways that would
prefer one solution over another, and/or are there
other compelling
arguments for one or the other alternative?

2) In a server implementation, is it required to have
index values
up to 2^32, instead of e.g. 1024 or even 16? Smaller
maximum values
would lead to faster wrapping and re-use even if re-use
is disallowed
according to the alternative mentioned on the interop
call. We allow
servers to limit the maximum number of attribute instances
for any
multi-instance attribute.

3) What about the situation when a single instance
of a multi-instance
attribute is added (with index 0) and then deleted.
If a new instance
is added, does it get index 0 or 1?


Any feedback is appreciated: comments, questions or
corrections if
my summary is not accurate or clear enough.


Regards,
Mathias