Interop testcase issues

On 4/02/2014 8:31 AM, Bruce Rich wrote:
I have a couple of
things in the current
set of interop testcases that I think need more discussion.
TC-152-11 and TC-152-12 (assuming
wd02a
is most current)

However
none of the Locate/Get pairs actually specify that they are
looking for
FRESH objects in that ObjectGroup, so there is no reason why
the second
Locate/Get would return anything other than the key that the
first one
did.  And thusly there is no reason that the third Locate/Get
would
fail to find a key.
Incorrect - those two test cases both contain the following in each
of the Locate requests:
X-NONE
X-NONE

<ObjectGroupMember
type=
Enumeration
value=
GroupMemberFresh
/>
That is precisely how return-only-fresh items was defined in KMIP
1.1 - quoting from 4.9 Locate ...
When the Object Group attribute and the Object Group Member flag
are specified in the request, and the value specified for Object
Group Member is ‘Group Member Fresh’, matching candidate objects
SHALL be fresh objects (see 3.34) from the object group. If there
are no more fresh objects in the group, the server MAY choose to
generate a new object on-the-fly, based on server policy. If the
value specified for Object Group Member is ‘Group Member Default’,
the server locates the default object as defined by server policy.
This is one of those strange situations where we could have handled
it via just specifying a Fresh attribute with a value of  true  but
alas for some unknown reason it wasn't specified that way so
separate handling has to be put in place to map that effectively
across.
MSGENC-JSON-1-10, 11, 12
(assuming wd03
is most current)

MSGENC-XML-1.10, 11, 12
At TIME 0, the client is
telling the
server that the maximum message size it can tolerate in the
response is
256 bytes, which would be tolerable for a TTLV-encoded
response.
Incorrect. The logic behind the alternate message encodings is that
you get  precisely  the same response on a logical KMIP
perspective as if you had used the TTLV encoding - that means any
message size calculations are performed on the TTLV equivalent
representation. HTTPS, JSON and XML are simply pure message encoding
translations. The size figures are not interpreted in a different
manner depending on the encoding format representation. This was
discussed way back when this was originally proposed and explicitly
noted in the test case within the document so there would hopefully
be less confusion on that topic.
It isn't an error in the test case. The entire set of test cases for
the test cases document and the test cases in the profiles documents
should be able to be run over TTLV, HTTPS-TTLV, HTTPS-JSON,
HTTPS-XML and always get identical results.
Tim.