OASIS Open Mailing List Archives  ·  All Lists  ·  kmip-interop-tech  ·  2011-05

kmip-interop-tech — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

Get Attributes


> When a client requests a list of attributes what should the server > behaviour be when an attribute is repeated more than once? > > The specification is silent on this topic. > > The current set of behaviours for servers are: > > 1) return only one result > 2) return copy of the result for each request > 3) reject the request returning OPERATION_FAILED > > I think the behaviour here should be well defined and not open to > interpretation especially where this may imply a limitation on what > the client can send to the server. > > My view at least is that 1) is the 'right' behaviour although the current > version of our C based KMIP server does 1) and our Java based KMIP > server does 2). > > Tim. > An example would be a client sending the following request, asking to get the CRYPTOGRAPHIC_ALGORITHM attribute twice: Tag: REQUEST_MESSAGE (0x420078), Type: Structure (0x01), Data:   Tag: REQUEST_HEADER (0x420077), Type: Structure (0x01), Data:     Tag: PROTOCOL_VERSION (0x420069), Type: Structure (0x01), Data:       Tag: PROTOCOL_VERSION_MAJOR (0x42006A), Type: Integer (0x02), Data: 0x00000001 (1)       Tag: PROTOCOL_VERSION_MINOR (0x42006B), Type: Integer (0x02), Data: 0x00000000 (0)     Tag: BATCH_COUNT (0x42000D), Type: Integer (0x02), Data: 0x00000001 (1)   Tag: BATCH_ITEM (0x42000F), Type: Structure (0x01), Data:     Tag: OPERATION (0x42005C), Type: Enumeration (0x05), Data: 0x0000000B (Get Attributes) Tag: REQUEST_PAYLOAD (0x420079), Type: Structure (0x01), Data:       Tag: UNIQUE_IDENTIFIER (0x420094), Type: Text String (0x07), Data: 2af5aadc-4891-4344-aaf8-f8dcaa9d709d       Tag: ATTRIBUTE_NAME (0x42000A), Type: Text String (0x07), Data: Cryptographic Algorithm       Tag: ATTRIBUTE_NAME (0x42000A), Type: Text String (0x07), Data: Cryptographic Algorithm 42007801000000D04200770100000038420069010000002042006A020000000400000001000000 0042006B0200000004000000000000000042000D0200000004000000010000000042000F010000 008842005C05000000040000000B00000000420079010000007042009407000000243261663561 6164632D343839312D343334342D616166382D6638646361613964373039640000000042000A07 0000001743727970746F6772617068696320416C676F726974686D0042000A0700000017437279 70746F6772617068696320416C676F726974686D00 The following is a response from our test server: 42007B010000012042007A0100000048420069010000002042006A020000000400000001000000 0042006B020000000400000000000000004200920900000008000000004DC90A8B42000D020000 0004000000010000000042000F01000000C842005C05000000040000000B0000000042007F0500 000004000000000000000042007C01000000A0420094070000002432616635616164632D343839 312D343334342D616166382D66386463616139643730396400000000420008010000003042000A 070000001743727970746F6772617068696320416C676F726974686D0042000B05000000040000 000300000000420008010000003042000A070000001743727970746F6772617068696320416C67 6F726974686D0042000B05000000040000000300000000 Tag: RESPONSE_MESSAGE (0x42007B), Type: Structure (0x01), Data:   Tag: RESPONSE_HEADER (0x42007A), Type: Structure (0x01), Data:     Tag: PROTOCOL_VERSION (0x420069), Type: Structure (0x01), Data:       Tag: PROTOCOL_VERSION_MAJOR (0x42006A), Type: Integer (0x02), Data: 0x00000001 (1)       Tag: PROTOCOL_VERSION_MINOR (0x42006B), Type: Integer (0x02), Data: 0x00000000 (0)     Tag: TIME_STAMP (0x420092), Type: Date-Time (0x09), Data: 0x000000004DC90A8B (Tue May 10 11:51:07 CEST 2011)     Tag: BATCH_COUNT (0x42000D), Type: Integer (0x02), Data: 0x00000001 (1)   Tag: BATCH_ITEM (0x42000F), Type: Structure (0x01), Data:     Tag: OPERATION (0x42005C), Type: Enumeration (0x05), Data: 0x0000000B (Get Attributes) Tag: RESULT_STATUS (0x42007F), Type: Enumeration (0x05), Data: 0x00000000 (Success) Tag: RESPONSE_PAYLOAD (0x42007C), Type: Structure (0x01), Data:       Tag: UNIQUE_IDENTIFIER (0x420094), Type: Text String (0x07), Data: 2af5aadc-4891-4344-aaf8-f8dcaa9d709d       Tag: ATTRIBUTE (0x420008), Type: Structure (0x01), Data:         Tag: ATTRIBUTE_NAME (0x42000A), Type: Text String (0x07), Data: Cryptographic Algorithm         Tag: ATTRIBUTE_VALUE (0x42000B), Type: Enumeration (0x05), Data: 0x00000003 (AES) Tag: ATTRIBUTE (0x420008), Type: Structure (0x01), Data:         Tag: ATTRIBUTE_NAME (0x42000A), Type: Text String (0x07), Data: Cryptographic Algorithm         Tag: ATTRIBUTE_VALUE (0x42000B), Type: Enumeration (0x05), Data: 0x00000003 (AES) So the behavior for our test server is the same as your Java server, i.e. 2). If the request is deemed acceptable, then I would prefer to define the behavior according to 2). If we choose to require that all attribute names specified in the Get Attributes request be unique, then we could also require that no attribute be returned more than once in the response, i.e. 1). Since neither requirement is currently there, option 3) makes the least sense to me. Thanks, Mathias

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]