[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: next meeting Monday 25, and some MS conf review feedback
All:
Conference call this Monday 25 :
Time: 11am PT
Host: Fujitsu
Toll Free - : 1-800-251-6413
Toll - : 1-913-905-1400
Participant code: 598136
Agenda will follow.
Mike:
Here is a partial feedback on the Test req list (focusing on those tagged "not testable")
Cheers,
Jacques
<<MSconf_comments.txt>>
General Notes: --------------------- - For requirement level column, we have sometimes "REQ", or "REC". -As an editorial note: all message actions ("received" "generated"...) are relative to teh candidate MSH ("...by MSH") Detailed: ---------- funreq_id_70:the assertion should be more explicit: "a message generated in response is sent on the same connection, e.g. an HTTP response, depending on the SyncReplyMode value". the message received was funreq_id_71 and _72: it is a REQ (not OPT) funreq_id_77 to _79: no Ack was received ---> and no Ack was generated (by the MSH) funreq_id_77 and _80: I guess one of them is redundant: "sent" means "received"? If it means "generated" (by the MSH), then we need to be more precised about "processed as if the interruption had not occurred." That measn for example, that after Recovery the MSH will resend the message the correct number of times if it does not receive an Ack. funreq_id_78 and _81: same as for _77 _80. funreq_id_80 and _82: same as for _77 _80. funreq_id_97: "For each *generated* Ack...": funreq_id_106: assertion: replace "The From Party MSH " by "the MSH" (this is the candidate, there is no other) funreq_id_114 _115: replace sent by "received" funreq_id_130: seems teatable to me ! we just analyze the Ack generated. funreq_id_131: I think it is "for each generated Ack", in the precond. funreq_id_137: seems testable: (replace "Sending MSH" by [candidate] MSH): test driver will observe the resending from MSH. funreq_id_138: spec ref is 6.5.4 (not 6.5.3) should be testable if the ErrorAppNotify is properly interfaced with candidate MSH, in Test Service. So we could say this in the test coverage. funreq_id_139: replace "sent" by "generated". (Check for replacing "sent" appropriately for all test reqs...) funreq_id_141: (and _142) I believe at least, we can check that the *same* Acks are sent back, independently on storage situation: ((For each message received, which is a duplicate of a reliable message previously received and the syncReplyMode is not set to none and The CPA indicates that an application response is included) then The generated Ack is returned on same connection, and is the same as the initially generated Ack. --- stopped review at _141 -----------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]