Fw: TC 152-11

[Bruce Rich <brich@us.ibm.com>]

Tony,

I would like to withdraw this request,
and not take interop participants through this discussion at this time,
so dropping it from the agenda would be fine with me.
There are still some gray areas in the
spec, but we will modulate our server behavior as per Tim's response (thanks,
Tim).

Bruce A Rich
brich at-sign us dot ibm dot com

----- Forwarded by Bruce
Rich/Austin/IBM on 01/28/2014 12:37 PM -----

From:      
 Bruce Rich/Austin/IBM
To:      
 kmip-interop@lists.oasis-open.org,

Date:      
 01/26/2014 07:22 AM
Subject:    
   TC 152-11

---

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).

The scenario is a batch of requests
with ordering turned on in the batch, where a Locate will not be able to
find any objects matching input parameters, and the subsequent request
(which is dependent on the success of the Locate and the placeholder holding
an appropriate UUID) will not be able to succeed.
The reason code for the result of the
second operation used to be InvalidField (in older versions of the testcase
doc).  In the current version of the interop doc, it has been changed
to be ItemNotFound.  There is no support in the KMIP specification
to mandate such a change (see detailed analysis below).  I am OK with
allowing InvalidField (as I do think it's more clear), but not requiring
it.

========== Detailed illustration =======================
(Spec quotes in italics)
TC-152-11, Time 6:

Batched Locate-Get with BatchOrderOption=TRUE
and BatchContinuationOption not set (default=STOP), so ID Placeholder can
be used.
In case Locate does not find any matches,
the ID Placeholder will be empty, and the subsequent Get will fail.
Issue: The test case shows (and requires)
the ResultReason=ItemNotFound. However, there is no text in the spec that
requires that the ResultReason be set to this value. SKLM returns InvalidField
in the failed Get response, since no UUID is provided.

From Section 4 Client-to-Server Operations,
line 1163:
The ID Placeholder is obtained from
the Unique Identifier returned in response to the Create, Create Pair,
Register, Derive Key, Re-key, Re-key Key Pair, Certify, Re-Certify, Locate,
and Recover operations. If any of these operations successfully completes
and returns a Unique Identifier, then the server SHALL copy this Unique
Identifier into the ID Placeholder variable, where it is held until the
completion of the operations remaining in the batched request or until
a subsequent operation in the batch causes the ID Placeholder to be replaced.

The Locate does successfully complete,
but it DOES NOT return a Unique Identifier. Nothing is mentioned what happens
in this case, e.g., if the ID Placeholder value should be invalidated;
therefore, if the ID Placeholder had some other previous value, it should
still be there, and the Get would actually return some (possibly) completely
different object that what the client was looking for in the Locate.

In Section 4.9 Locate, line 1425:
If a single Unique Identifier is
returned to the client, then the server SHALL copy the Unique Identifier
returned by this operation into the ID Placeholder variable.  If the
Locate operation matches more than one object, and the Maximum Items value
is omitted in the request, or is set to a value larger than one, then the
server SHALL empty the ID Placeholder, causing any subsequent operations
that are batched with the Locate, and which do not specify a Unique Identifier
explicitly, to fail. This ensures that these batched operations SHALL proceed
only if a single object is returned by Locate.

Again, nothing is said here either about
what happens when the Locate does not match any object.

In Table 167, Section 4.11 Get, line
1511, Description column of Unique Identifier:
Determines the object being requested.
If omitted, then the ID Placeholder value is used by the server as the
Unique Identifier.

No mention of valid values for the ID
Placeholder, e.g., if it is empty.

There are no error definitions in Section
11 that describe situations where a previous Locate succeeded, but returned
no UUIDs, and subsequent operations trying to use the ID Placeholder fail.

Based on this, I would say that any
implementation that returns e.g., InvalidField in the Get response at Time
6 in TC-152-11 is spec-compliant, and the testcases must not mandate a
particular response where the spec does not support it.
 ========= End of detail ===================================

Bruce A Rich
brich at-sign us dot ibm dot com