kmip-interop-tech — archive

[Tim Hudson]

> On last week's interop-call, the people present (John and Stan of HP, Alan and > Paul of SafeNet and myself) discussed how to proceed with the proof-of-concept > interop calls and the interop-effort in general. We agreed that in light of the > current lack of interop-activity, it would make sense to take a "summer > vacation" from the interop-calls, and resume at a later date when there is more > to test. I (incorrectly) assumed the call wasn't on given that Bob canceled the main call and the previous weeks call was somewhat short or I would have joined the call. > I propose to cancel this Thursday's interop call and bring the definition of new > use cases up as an agenda item on the TC call with the larger group. I agree with the approach. Although the wider group seems to be somewhat less enthusiastic about practical implementation issues. I'd like to canvas opinions on the topic of adding additional simple use cases or changing the current use cases to allow for testing of each 'feature' independent of the rest of the logic. The current use cases have a mix of features in them and I found during implementation that more ancillary stuff had to be implemented for certain use cases. e.g. 3.1.4 required GetAttributeList, AddAttribute, ModifyAttribute, and DeleteAttribute to be implemented in a use case focused on Dual Client use and 4.1 Revoke also has AddAttribute, ModifyAttribute, and DeleteAttribute. I do understand that the use cases are not intended to be a set of unit tests, however we all seem to be using them to test incremental implementations and are hitting blocks of functionality intermixed. I've also been testing outside the use case context so turning those tests into use cases would be straight forward to do. Tim.