Re: [kmip] Groups - proposal_for_attribute_index-v1.doc uploaded

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

In Section 3 we say "Attributes
that an object MAY have multiple instances of are referred to as multi-instance
attributes.", and in the Custom Attribute Rules table in Section 3.34,
we say "Multiple instances permitted: Yes". While a server (or
client?) may place further restrictions on how many instances of each attribute
are actually allowed, I would still say that we need to treat all custom
attributes as multi-instance attributes.

To further avoid confusion, I would
be fine with requiring the attribute index to always be specified as suggested
in Bruce's note. We have specified the error cases that deal with situations
that occur if the attribute index is explicitly indicated and that index
does not exist. I see how an approach similar to the one taken in 2.1.6
would be possible, but I also feel that this approach is a more significant
change to what we have in v1.0.

Thanks,
Mathias

From:	Bruce Rich <brich@us.ibm.com>
To:	Tim Hudson <tjh@cryptsoft.com>, mbj@zurich.ibm.com, indra.fitzgerald@hp.com
Cc:	kmip@lists.oasis-open.org
Date:	24.08.2011 17:34
Subject:	Re: [kmip] Groups - proposal_for_attribute_index-v1.doc uploaded

---

Then the proposed language for the spec
updates is perhaps not yet clear enough.  If we are saying that the
client may omit the index, but the server always returns an index, even
if it is a single-valued attribute (defined in spec as single-valued, in
which case the server returns an index of zero) or a known multi-valued
attribute (defined in spec, and server knows the index because it created
it) or an attribute whose valued-ness is not yet known (client custom attribute
and server only knows about first value of that attribute and assigned
an index of zero), then we need to say that. 

To illustrate, the update in section 2.1.1 should say, "If the attribute
index is not specified by the client, it is assumed to be zero."
The update in section 4  and 5 should say, "The Attribute Index
of multi-instance all attributes SHALL always be set when
attributes are returned by the server, even if the attribute is known to
be single-valued so the index is zero." 

Indra's proposal to allow DeleteAttribute to remove the lowest-indexed
instance of an attribute (if the index is omitted) may cause some significant
changes on KMIP servers if adopted, but would allow a client who wants
to remain oblivious to the index of an attribute to do so.  I'm just
not sure that we should enable that level of not caring...seems almost
like covering up someone's addiction problem. 

Bruce A Rich
brich at-sign us dot ibm dot com




From:        Tim
Hudson <tjh@cryptsoft.com> 
To:        Bruce
Rich/Austin/IBM@IBMUS 
Cc:        kmip@lists.oasis-open.org
Date:        08/23/2011
05:26 PM 
Subject:        Re:
[kmip] Groups - proposal_for_attribute_index-v1.doc uploaded

---

On 24/08/2011 7:26 AM, Bruce Rich wrote: 
Hmm, what do we do for the Custom Attributes ("x-*" and "y-*")?
 For the y-*, the server should know whether they are multi-valued,
so can know whether or not to return a 0 index for the first/only instance.
 But for custom client attributes, the server doesn't know that it's
multi-valued until the second AddAttribute for the same x- name. 

I think we may need to assume that custom client attributes are always
multi-valued and thus the server always includes an index for x- attributes

The attribute index handling should be identical for all attributes - entirely
independent of whether they are custom attributes or multi-valued.

There are a couple of choices:
- either an index value shall always be provided; or 
- if an index value is not present it shall be assumed to be '0'

That's how it should be handled in all contexts - a rather simple rule.

The whole approach of having different rules for how to handle is what
the proposal is about addressing - to get back to a simple situation -
and one where there is a chance that implementations will actually be able
to match the specification :-)

Tim.