MHonArc v2.5.2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: Re: [ebxml-msg] Reliable Messaging question
Dick et al,
I agree that ErrorList@highestSeverity="Error" is a great way to end
the retry loop in other specifications. I also agree this is common
practise and something worth including in our specification.
Unfortunately, the current document is very explicit in 7.5.4 and elsewhere.
It makes it clear communication errors result in additional retries and
that Retries or receiving an Acknowledgment are the only ways to end the
retry loop. See bullets starting at 1716 for example. We use
MUST in many of those comments.
My issue 125 addressed an apparent conflict between these explicit rules
and some of the error semantics. I'm not sure why I originally made
the comment on line 1352 (section 4.2.4.1); lines 1312-1313 (section 4.2.3.2.4)
would have been more appropriate. In any case, 4.2.3.2.4 says the
ErrorList stops everything but the rest of the document says only Acknowledgment
stops retries.
To Michael's point about deferring a correction in this area 'til a
later version, I'd say the current conflicting MUST requirements need to
be fixed now. Changing the document to explicitly include ErrorList@highestSeverity="Error"
in the exit points for the retry loop is a fine solution. I didn't
like a need to bundle an Acknowledgment with such an ErrorList but didn't
see a simpler way to correct the problem.
thanx,
doug
Dick Brooks wrote:
>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
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.
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC