>David's comment makes sense. I can't think of
a reson why I would respond
>in the same message with an Acknowledgment
element AND an ErrorList
>element . I would only ack a message
after all MSH level related validation
>has passed.
I
concur, ErrorList and Acknowledgement are mutually exclusive in the
OTA and
Energy
ebXML specs I've worked with, here are excerpts from the two
specs:
Energy
spec:
"NOTE: The existence of an Acknowledgement element in a Response
indicates that a Request was processed successfully. The existence of an
ErrorList element in a Response indicates that a Request has failed. When a request message contains
deliverySemantics of “OnceAndOnlyOnce” its corresponding response message MUST
contain either an <Acknowledgement> or <ErrorList>
element."
OTA
spec:
"The existence of an Acknowledgement
element in a Response indicates that a Request message was successfully
received. The existence of an ErrorList
in a Response indicates that a Request has failed. "
Dick Brooks
Systrends, Inc
7855 South River Parkway, Suite
111
Tempe, Arizona 85284
Web: www.systrends.com <http://www.systrends.com>
Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714
-----Original Message-----
From: Michael Wang
[mailto:]
Sent: Thursday, February 14, 2002 2:57
AM
To:
Subject: Re:
[ebxml-msg] Reliable Messaging question
If the position is
to let the retry kick in then are we saying the sender MSH
should "ignore"
the ErrorList message and just let the retry to complete?
Then report back
to application of the N retries it did and all the Errors it
got back?
David's comment makes sense. I can't think of a reson why I would
respond
in the same message with an Acknowledgment element AND an
ErrorList
element . I would only ack a message after all MSH level
related validation
has passed.
May be too late for 2.0 but I would say this introduces unnecessary
complexity.
Should probabaly be looked into post 2.0.
-mw
Doug Bunting wrote:
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:]
Sent: Wednesday, February 13,
2002 7:23 PM
To:
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
winmail.dat
