[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [kmip] TTLV encoding concern
Responding in order of replies received …
Mark Joseph wrote:
> I thought that the idea of using string names for attributes allows the use of
> X- and Y- attribute name extensions that you could not do with a fixed set of codes.
My proposal maintains the ‘x-‘ and ‘y-‘ prefixes specified for custom attributes. Of course, no client- or server-defined attribute could be expected to have an associated object tag defined in the KMIP specification; rather, the specification defines a single Custom Attribute (42002D) whose Attribute Name field serves to distinguish one Custom Attribute from another. For example:
Tag: Custom Attribute (0x42002D), Type: Structure (0x01), Data:
Tag: Attribute Name (0x42000A), Type: Text String (0x07), Data: x-My Custom Client Attribute
Tag: Attribute Index (0x420009), Type: Integer (0x02), Data: 0x00000002 (2)
Tag: Attribute Value (0x42000B), Type: Integer (0x02), Data: 0x00000011 (17)
Only a Custom Attribute strictly requires the presence of the Attribute Name field. The object tag is sufficient to prime the parser to anticipate the mandatory and optional fields:
Attribute Name: REQUIRED=Yes (and must be prefixed by ‘x-‘ or ‘y-‘)
Attribute Index: REQUIRED=Yes, if Index!=0
Attribute Value: REQUIRED=Yes, except when present in a Notify
So, Custom Attributes are distinguished from each other by their x- or y-prefixed Attribute Names. The Custom Attribute’s associated object tag (0x42002D) does the job of any object tag: Within a KMIP PDU, it serves to delimit its corresponding KMIP element.
Tim Hudson wrote:
> What you are actually asking for is an incompatible change to the basic
> encoding used for attributes - not a clarification.
Actually, the proposal is completely forward-compatible with existing usage. In fact, the existing encoding (---) and the proposed encoding (+++) could be intermixed in the same KMIP request or response without conflict:
As for the clarity/ambiguity of the specification, I believe that the text of Section 3.39 Custom Attribute clearly indicates that attributes were expected to be encoded as I am proposing:
3.39 Custom Attribute
A Custom Attribute is a client- or server-defined attribute intended for vendor-specific purposes. It is
created by the client and not interpreted by the server, or is created by the server and MAY be interpreted
by the client. All custom attributes created by the client SHALL adhere to a naming scheme, where the
name of the attribute SHALL have a prefix of 'x-'. All custom attributes created by the key management
server SHALL adhere to a naming scheme where the name of the attribute SHALL have a prefix of 'y-'.
The server SHALL NOT accept a client-created or modified attribute, where the name of the attribute has
a prefix of ‘y-‘. The tag type Custom Attribute is not able to identify the particular attribute; hence such an
attribute SHALL only appear in an Attribute Structure with its name as defined in Section 2.1.1.
The paragraph states that tag type is not sufficient to identify a Custom Attribute, but correctly infers that every other Attribute can be identified by its object tag. If attributes were not expected to be identified by object tag, there would have been no need to even mention “tag type” in the above description.
On 27/06/2014 5:38 PM, Featherstone, David wrote:
The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.