kmip message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [kmip] Groups - proposal_for_attribute_index-v1.doc uploaded
- From: Bruce Rich <brich@us.ibm.com>
- To: Tim Hudson <tjh@cryptsoft.com>, mbj@zurich.ibm.com, indra.fitzgerald@hp.com
- Date: Wed, 24 Aug 2011 09:51:20 -0500
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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]