RE: [ebxml-iic-conform] MS Level 2 & 3 test reqs

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

Mike:

 

my comments attached, for Level 3 and some leftovers for level2.

 

cheers,

 

Jacques

 

-----Original Message-----
From: Michael Kass [mailto:michael.kass@nist.gov]
Sent: Wednesday, July 03, 2002 8:40 PM
To: Jacques Durand; "'ebxml-iic-conform@lists.oasis-open.org'"@fujitsu1a.fujitsu.com
Cc: matthew MacKenzie; Monica Martin
Subject: Re: [ebxml-iic-conform] MS Level 2 test reqs

Jacques and all,

Here is iteration #2 of level 2 requirements, with changes as per attached comments.  My comments are
preceded by [MIKE2].

Also, here is the first "go-around" for level 3 requirements.  Comments welcome.

Mike

Comments from Jacques:


-------------------- remaining Level 2 comments ----------------------

r2.1.1.2: should be removed and merged with r2.1.1.1 , as it is redundant somehow (with r2.1.2):
(and I'll try to remove this "optional" as well ...)

r2.1.1.1: 
[precondition]: sending M reliably, in case MSH behavior is to resend,
if an Ack is received before  all retries are expired.
[assertion]: REQUIRED: the MSH stops resending M and behaves as if M successfully delivered.

r2.1.2:
[precondition]: For each reliably generated message, if the MSH is configured to resend AND 
if the candidate MSH fails to receive  any Acknowledgment meesage from a receiving MSH. 
[assertion]: REQUIRED: 
The candidate MSH sends successive retries at expected time intervals, 
then notifies From party of delivery failure.

r2.1.14: should be split for each subcase:
r2.1.14a:
[precondition]: For each received message with an AckRequested with the Signed attribute set to True
if the Receiving MSH supports signed acknowledgment messages 
[assertion]: REQUIRED: the MSH sends back a signed acknowledgment.

r2.1.14b:
[precondition]: For each received message with an AckRequested with the Signed attribute set to True
consistent with CPA, and if the Receiving MSH does NOT supports signed acknowledgment messages 
[assertion]: REQUIRED: the MSH generates an Error of type Inconsistent, and severity = Error .

r2.1.14c:
[precondition]: For each received message with an AckRequested with the Signed attribute set to True
NOT consistent with CPA, and if the Receiving MSH does NOT supports signed acknowledgment messages 
[assertion]: REQUIRED: the MSH generates an Error of type Inconsistent, and severity = Warning .

r2.1.14d:
[precondition]: For each received message with an AckRequested with the Signed attribute set to False
if the Receiving MSH supports unsigned acknowledgment messages 
[assertion]: REQUIRED: the MSH sends back an unsigned acknowledgment.


r2.1.33.X: all these should have RECOMMENDED (as the spec says SHOULD)
NOTE: I believe in several places, OPTIONAL should be converted in RECOMMENDED
(e.g. r2.1.38, etc.)

---------------------------- Level 3 comments ---------------------------

r3.1.1: spec ref should be 7, not 8. (need be changed in all other reqs)
[assertion]: RECOMMENDED:A Status Response Message is returned, with an Action
as StatusResponse.

r3.1.4: RECOMMENDED


r3.1.5: (rewording)

[precondition]: for each Status Request messages generated, i.e.
with an Action element = StatusRequest. 
[assertion]: REQUIRED: the message consists of no payload and the MessageHeader/StatusRequest elements ...etc.

r3.1.7: coverage  is probably "partial", as it is not clear that we can
generate unauthorized calls to the  MSH (not specified what it means).
(and thsi coverage will now be associated with section 7.1.3 in spec).


r3.1.9: 
RECOMMENDED only (see 7.1.2). In fact, although the production of a StatusResponse is
NEVER mandatory, when it occurs we should require that all fields are well formed
and conforming. 
One way to do that is to include the generation of StatusResponse in precondition.
That is what you want to verify here it seems, not that the response is actually
generated (which is handled by r3.1.1, the precond of which is similar or almost).
So I suggest: 
- we let r3.1.1 verify the (recommended) generation of a response, without more checks.
- we transfor r3.1.9:
[precondition]: For each received message, if the message contains a StatusRequest element 
AND If the StatusRequest child RefToMessageId element value is recognized by the MSH 
AND If the message is received from an party deemed to be authorised 
AND if a Status Response is generated for this Request.
[assertion]: REQUIRED: the Response message is consistent with all reqs as in (7.3),
and has a RefToMessageId consistent with the Status Request message.
 

r3.1.10.1: shouldn't we merge aslo with r3.1.9 ?
as the preconds are pretty much the same and the assertions could be consolidated
or mayn actually be included in r3.1.9  ?

r3.1.10.2 - r3.1.10.3: we should use same trick: 
[precondition]: ...AND if a Status Response is generated for this Request.
Only then can we REQUIRE the assertion...

r3.1.12: can't relate to the spec (section 7.1.3?).

r3.1.13: mostly rewording, but also necessary to have a REQUIRED assertion:
[precondition]: ( For each received message, if the message contains a StatusRequest element 
AND If the the StatusRequest child RefToMessageId element value is recognized  <---- remove that one, redundant with (b)?
 AND If the message is received from an party deemed to be authorised 
AND If the message identified by the RefToMessageId element	<---------------------------- (b)
 in the StatusRequest element has been received by the MSH 
AND if a Status Response is generated for this Request)  <------------------------- added
[assertion]: REQUIRED: messageStatus in StatusResponse has a value 'Received' 


r3.1.14 and r3.1.15: same rework as above.


r3.2.2: OPTIONAL --> RECOMMENDED
also: "...an errorCode of "NotSupported" and a highestSeverity attribute set to Error."

r3.2.4: this "optional" will spoil the testing...
I'd suggest the same approach we had above (r2.1.2:"... if the MSH is configured to resend ..."):
we assume the service is operational and we state it in the pre-condition:
(otherwise, there is no way to validate if the Ping service really works when every party agrees
it should!) 
[precondition]: For each received message, if  (a) the message header Action element contains 
a child Ping element AND (b) The requested service is supported AND (c) the Ping request is occurring under
normally expected conditions (unlike those described in 8.3). 
[assertion]: REQUIRED: <same as before>

NOTE: when there are such "assumptions" (same for r2.1.2) maybe we can make a list of these,
ask the testee to confirm his/her MSH should behave that way for the tests.
and make that part of our CPA-like MSH configueration. I.e. in case
the testee cannot/will not confirm an assumption, then  the Test Reqs that
use it as pre-condition will not be satisfied and 
the Test Case will simply not apply.

r3.3.4: we should move some of the assertion in precond:
[precondition]: 
For each generated multi-hop message, with a SOAP actor attribute value targetting the NextMSH,
if reliability is used
[assertion]: there will not be two AckRequested elements in the message .

r3.3.8: reword: (note the multi-hop MSH MUST differentiate the Ack requests, as in section 10.1.3)
[precondition]: ( For each received multi-hop message, if it contains
 two AckRequested elements where one addresses NextMSH and another addresses ToPartyMSH, 
AND the receiver - candidate - MSH is the ToParty MSH. )
[assertion]: REQUIRED: the candidate MSH is in the combined role of Next and ToParty MSH, and
will send  two Acknowledgments.

r3.3.9: use precondition:
[precondition]: For each multi-hop message received reliably,  
if the candidate MSH node is in the role of intermediary, 
[assertion]: REQUIRED: the message is not acknowledged until both persisted and delivered to the Next MSH.

r3.3.14 and r3.3.15: use precondition too.
(in fact, to be consistent, every req item should have a precond, as it relates to either
sending or receiving a multi-hop message).