+1
David
-----Original Message-----
From: Doug Bunting
[mailto:]
Sent: Thursday, February 14, 2002 11:23
AM
To:
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
-----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
