Re: [ebxml-msg] Reliable Messaging question

[Doug Bunting <dougb62@yahoo.com>]

David,

Almost every error may be transient.  Further, our documentation gives no "out" for the sending MSH other than exceeding the Retries parameter or receiving an appropriate Acknowledgment.  Adding the ErrorList element to that list of outs would be very different from 1.0 and would involve multiple changes to our document.  That's in spite of the a receiving MSH already being able to send ErrorList and Acknowledgment together.

125 was an editorial issue because the other parts of our specification were clear what could stop retries.  The section referenced in issue 125 muddied things.  Let's not turn this into a new technical issue.

thanx,
    doug

David Fischer wrote:

 Why would an MSH continue sending retries after receiving an ErrorList for that MessageId?  Section 6.5.7 indicates that when a message cannot be delivered then a DFN must be returned.  You are right though, it doesn't actually say not to send any more retries. I'm a little confused...  If an Acknowledgment is present with an ErrorList, does that mean the MSH does or doesn't send a DFN to the application?  I suppose if the message got far enough so that the receiving MSH could actually generate an Acknowledgment then that would constitute delivery for the purposes of RM? I think this would be OK -- send an ErrorList and an Acknowledgment together.I'm still not clear why the sending MSH would continue to send retries if it got an ErrorList (containing the appropriate RefToMessageId) from the receiving MSH but without an Acknowledgment?Regards,David FischerDrummond Group.

-----Original Message-----
From: Doug Bunting [mailto:dougb62@yahoo.com]
Sent: Wednesday, February 13, 2002 7:23 PM
To: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Reliable Messaging question
 

Arvola,

I believe this is captured in issue 125.  In David's response [1], he indicated an ErrorList could end retries but that interpretation is not borne out by our current documentation and seems incorrect.  I would suggest we stick with the current retry semantics and end retries only upon receipt of an Acknowledgment or exhaustion of allowable retries.  If a MSH receiving a message in error chooses to respond with an Acknowledgment bundled together with an ErrorList, fine.

I also agree this option (combining Acknowledgment with ErrorList) isn't well described.  Improving that description was the intent of issue 125.

thanx,
    doug

[1] http://lists.oasis-open.org/archives/ebxml-msg/200202/msg00006.html (specifically, the XML file attached and unhelpfully inlined by the OASIS site)

Arvola Chan wrote:

 Section 7.5.2 in Draft version 2.0 describes Receiving Message Behavior under the ebXML Reliable Messaging Protocol. It does not mention anything about error handling. Suppose the received message is erroneous (e.g., some elements in the message are inconsistent with the CPA), the receiver is obligated to return an Error message. It is not clear to me if an Acknowledgment MUST also be included in the Error message. Does the Error message serve as an implicit Acknowledgement? Will the sender keep retrying until it gets back an Acknowledgment (i.e., as long as the number of allowable retries have not been exhausted)? Thanks,-Arvola