[ebxml-iic-conform] MS Level 2 test reqs

r2.2.5:re-wording: 
[precondition]: the MSH allows for specifying maximum of received out-of-order 
messages, 
and this maximum has been reached for a given conv ID. 
[assertion]: REQUIRED: MSH notifies sending MSH with delivery failure (with 
code...). 

[MIKE] - Spec does not infer that allowing for a maximum # of out-of-order
messages is an option.. it infers that this is a requirement.. If it is an option,
then it should be specified as such.. therefore the [precondition] is not a 
condition at all, in my opinion. It is also not testable as a condition.
Reworded, but the condition is whether "max" unsequenced message count has been reached.

[Jacques]: you are right: I interpreted the "if" below as an implementation option:
"...If the implementation defined limit for saved out-of-sequence messages is reached, 
then the Receiving MSH MUST indicate a delivery failure to the Sending MSH with errorCode set
 to DeliveryFailure and severity set to Error (see section 4.1.5). ..."


r2.2.6a: re-wording: (consolidated with r2.2.7a) 
[precondition]: sending message with MessageOrder element, which is first for a 
conversation ID 
[assertion]: REQUIRED: the sequenceNumber element must have value 0, 
and its Status attribute = "Reset". 

[MIKE] - DONE


r2.2.7b: could be consolidated with r2.2.6b. 



[MIKE] - DONE ( also consolidated with r2.2.6a )


r2.2.8: (rewording) 
[precondition]: sending message with MessageOrder element, 
[assertion]: REQUIRED: the sequenceNumber element has Status attribute = "Reset" 
or "Continue". 


[MIKE] - DONE 


r2.2.9: not correct as stated: (sounded like reset *must* be done if 
precondition is true.) 
[precondition]: when sending message with MessageOrder element, and Status 
attribute = "Reset" 
[assertion]: REQUIRED: all previous messages for this conversation must have 
been accounted for 
(Acks received). 
(Note: can only partially be verified... as I believe the reset is controlled by 
the MSH, 
not the app) 


[MIKE- - DONE

r2.2.10: we could restate this using precondition: 
[precondition]: when sending message with MessageOrder element, 
[assertion]: REQUIRED: no SyncReply element is present. 

[MIKE] - This is covered in "merged" r2.2.2

[Jacques]: You are right. 

[precondition]: when sending message with SyncReply element, 
[assertion]: REQUIRED: no MessageOrder element is present. 

[MIKE] - DONE

[Jacques]: Is that one translated into r2.2.10.2 ? if yes, we should
not have "...AND No MessageOrder element is present " in the precondition,
as that should represent the Assertion of the test req.
In fact, These two test reqs: r2.2.10.1 and r2.2.10.2 are not well written,
as their assertion is automatically implied by their precondition, it seems.
I believe r2.2.10.1 is subsumed by r2.2.2, if it is same as my previous r2.2.10 above.

 

r2.2.11: "RECOMMENDED" instead of OPTIONAL ("should" in spec) 

[MIKE] - DONE

[Jacques]: I still see "OPTIONAL" in r2.2.11 assertion...(should be "RECOMMENDED")

r2.3: assume all these test reqs are moved to Level 3, review later... 

[MIKE] - DONE