OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-iic message

[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


Title: 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]