[ebxml-iic-interop] interop test cases: 3 proposed (ultimate...)updates

[Jacques Durand <JDurand@fsw.fujitsu.com>]

Title: interop test cases: 3 proposed (ultimate...) updates

All:

following on the call this morning, here is three proposed updates on the basic interop test suite
as it is drafted today (V0.7) I attach a sample of "minicpa" that IPNetSolutions provided some time ago.

Can we get closure on these by this end of week? (i.e. make a decision either way)

Regards,

Jacques
<<minicpa.xml>>
---------------------------------------------------------------------

Proposed items for discussion on the basic interop test suite:

1. Test Case 1.5 is about testing interop of signed messages, with
key info embedded in the message. Alternative is Test Case 1.6, where
the key comes from preinstalled certificate.
Proposal is to remove 1.5 from this suite. Rationale is:
- vast majority of use cases will not embed keys in messages, according to users, but use a key from certificate,
which 1.6 is testing. So 1.6 is sufficient for a "basic" interop suite.
- ability to make proper use of embedded key info can be tested in conformance tests. Testing the
interop aspect of it does not add much to this test, or to cross-partners key handling (which 1.6 does too)
Would rather belong to a more advnaced interop suite if any.

2. The way we specify our CPA content (see the set of "abstract" CPAs in 3.4.2)  is not complete enough:
these abstract CPAs do not distinguish between the parties involved (e.g. they just say: "Signature: yes"
but do not say which party , or if both, should sign).
That means we may have a bit of inconsistency in test cases like 1.6:
It says that one way is signed (sending), while the other way is not (response).
I suggest we enhance a bit the CPA abstract description so that it distinguishes the two
parties (something closer to the "minicpa" from IPNet - e.g. MessageInfo for each party - that I attached to this mail?)

In our test cases, we do not need each party to be required to exercise exactly the same capability as the other:
checking signature validation on one side only is enough, because our test suite being asymmetrical,
it is supposed to be executed twice anyway, once from each side. That means both parties will be covered anyway.
And exercising each capability separately (in asymmetric way) is better for trouble shooting.

3. In our current test suite, we always do payload verification (compare with reference payload)
on the sender side, after the payload has done the full loop sender->receiver->sender.
We always send indeed our payloads to "Reflector" action (1.2, 1.3, 1.5, 1.6, 1.7).
Proposal is to have at least one of these tests (e.g. 1.2) do payload verification on the destination side,
by sending to "PaylodVerify" action. Rationale is:
- It is good to have a test case that does not do too much at once: it will test only one-way interop of payloads.
So if there is a problem, its easier to narrow down where it is. (if all test cases verify the payload(s) after a full loop,

we wont know which way had a problem after a failed comparison...). PayloadVerify will send back the status
in a small predefined doc, as specified in TestFramework. So that is what Test 1.2 could verify on sender side:
contetn of this status which said if payload was identical or not on receiver side.

Attachment: minicpa.xml
Description: Binary data