[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [kmip] Groups - kmip-spec-v1.1-csprd01-attribute-index-update-summary.pdf uploaded
All, Comments below on attribute index, as requested at TC meeting. 2.1.1 Attribute "The Attribute Index is an index number assigned by the key management server when a specified named attribute is allowed to have multiple instances." I think this should be changed. All attributes should have an index. (See below for discussion on whether the index should or shouldn't always be specified - that's a separate set of arguments.) "Single instance" attributes should probably always have index number 0. I am concerned that some attributes may change from single instance (in 1.0 and 1.1) to multiple instance in later versions of the specification (e.g. see Michael Steven's comments on the v1.1 specification that show obvious examples of why this should happen). This may cause some confusion at best, or conflicts at worst, about how to handle the indices in future. I am also concerned about custom attributes. There is no flag that allows a client or server to work out if an attribute is single or multi-instance. I suppose that it could be worked out by trying to create multiple instances, and observing the result. But this is not a method that I would encourage or purposely build into a specification. I am not suggesting that we add such a flag, just making the observation that clients and servers may not know whether an attribute must be single-valued, or can be multi-valued. The net result of my two concerns above, is that I think it would be more consistent, flexible, and future-proof if all attributes were treated as if they could be multi-instance. "Attributes that have a single instance have an Attribute Index of 0, which is assumed if the Attribute Index is not specified." Does this mean single-instance attributes, or does it also include multiple-instance attributes that currently only have a single instance specified? This needs to be clarified. For the first case (i.e. single-instance attributes), a simple change of wording will make this clear; e.g. “Single-instance attributes shall have an Attribute Index of 0, ..." For multiple instance attributes that currently have just a single instance, the requirement for an index of 0 would conflict with the requirement not to change index values; e.g. an attribute has two instances, indices 0 and 1; delete instance 0; now have an attribute with a single instance with index value of 1. Table 2: Attribute Object Structure The proposed change in this table is that the Attribute Index not be a required value. The text in this section says that when an Attribute Index is not specified, the index value of 0 should be assumed. This conflicts with the Add Attribute operation request message which states that no attribute index should be specified (and the index is allocated by the server, and may not be 0). Maybe need some clarifying words for the Add Attribute text to say that for this operation, unlike the other attribute operations, the absence of an attribute index (in the request) does not mean index 0 (which would always be an error). But the response can optionally omit the index, and when it does so the index can be assumed to be 0. (Personally, I'd find it much simpler if the response always returned an index value. This would save a lot of explanatory text around the exceptions for some operations and/or request/response different interpretations of missing indices.) No new text has been proposed for the Get Attributes operation. Does a missing index value for the response mean that the index value is 0? I assume that it would be legal for a multi-instance response to contain, for example, an instance with no index (assumed 0), and another instance with index, say 1; i.e. instances where one has no index value, and other instances that have index values. Technically this is workable, but it just doesn't feel right. I would prefer to see an explicit index value returned for all instances (including single-instance attributes). No technical reason for this, just for consistency and hopefully easier future expansion of attributes and attribute operations. 4.14 Add Attribute. See comment above (request does not specify index, but this does not mean index is 0). John From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Tim Hudson Submitter's message
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]