kmip-interop-tech — archive

[Bruce Rich <tjh@cryptsoft.com>]

Tim, I'm not convinced. For standards-based interop, it's best to be very careful what you emit, but lenient about what you receive.  And both servers are following this rule, as they aren't responding with #3. In both cases 1 and 2, after the call the client will now know a value for each distinct attribute (by name) that they asked for.  So both servers are supplying what's needed. In case 2, the server is trying to respond to the client in terms that it can best understand. In case 1, the server had to do extra work to pre-scan to eliminate duplicates, which penalizes all non-stuttering clients but does conserve a bit of network bandwidth. If the spec must speak to this, I would prefer that we explicitly say that the server SHOULD NOT fail a stuttering client and remain silent about the rest. Bruce A Rich brich at-sign us dot ibm dot com From:         Tim Hudson <tjh@cryptsoft.com> To:         kmip-interop-tech@lists.oasis-open.org Date:         05/09/2011 07:37 PM Subject:         [kmip-interop-tech] 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. --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php