Re: [kmip-interop] TC 152-11

[Tim Hudson <tjh@cryptsoft.com>]

On 26/01/2014 11:25 PM, Bruce Rich wrote:

I am petitioning the Interop Subcommittee to permit two possible reason codes for one particular scenario (may play out in multiple tests, but is illustrated in TC 152-11).

It is good to see a detailed write up of the context.

The error return reason code for a non-existing Unique Identifier value has always been ItemNotFound.

The test cases are informative not normative and where the test case return codes that have clashed with the specification text they have been adjusted during the various interops over the last four years to align as more checking of those values has occurred unless multiple interpretations of the specification allowed for different values. Quite a few of the 1.0 test cases changed where they simply did not match the specification.

This particular issue in my view is very clear - there is a defined error code for not matching a Unique Identifier and it is normative - Section 11 is rather clear with " This section details the specific Result Reasons that SHALL be returned for errors detected.". That error reason code specified in the tables for each operation SHALL be returned. Other codes are invalid (non-conforming).

On what should happen with ID Placeholder (which is an entirely separate item) when it matches no objects the specification is indeed less clear than it should be - but it does contain the statement you have quoted in the definition of Locate - "This ensures that these batched operations SHALL proceed only if a single object is returned by Locate." - the intent clearly is to not allow a Locate which is empty to leave the ID Placeholder value intact for subsequent batched operations to use the previously set value.

I don't think you are advocating that the ID Placeholder value should be preserved in this circumstance and are just pointing out a potential gap in the specification where it could be clearer - or am I misreading the email?

Thanks,
Tim.