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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: [ebxml-msg] Reliable Messaging question

I agree, possibly "conversation" is inappropriate in
this context. I would think that from the MSH's perspective,
that the referenced message is terminated, no further
retries are attempted (by the MSH, in the context of RM)


Dick Brooks wrote:

> David,
> I'm not sure I understand this statement from the spec: "...there is an 
> unrecoverable error in the message and no further messages will be 
> generated as part of the conversation."   
> If a ConversationID is synonymous with a "Session" there will likely be 
> multiple message exchanges, including some with ErrorList, throughout 
> the course of the session. IMO, the spec should not dictate the behavior 
> of a Conversation, this is application specific. 
> It may be the intent of this statement is to indicate the "responder" 
> will send no further "responses" after issuing an ErrorList. That is 
> understandable. However, a client MUST be able to send additional 
> request messages over the same ConversationId, after receiving 
> an ErrorList response, and the server should be able to respond to these 
> additional requests.
> Dick Brooks
> Systrends, Inc
> 7855 South River Parkway, Suite 111
> Tempe, Arizona 85284
> Web: www.systrends.com <http://www.systrends.com 
> <http://www.systrends.com/>>
> Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714
>     -----Original Message-----
>     From: David Fischer [mailto:david@drummondgroup.com]
>     Sent: Thursday, February 14, 2002 11:04 AM
>     To: mwang@tibco.com; ebxml-msg@lists.oasis-open.org
>     Subject: RE: [ebxml-msg] Reliable Messaging question
>     The spec says, in section, that if there is an error
>     severity of Error, "...there is an unrecoverable error in the
>     message and no further messages will be generated as part of the
>     conversation."  How can we then continue to send retries after an
>     ErrorList with error severity of Error? 
>     Maybe the problem we need to clarify is in the Error section rather
>     than in the RM section?  OTOH, maybe the statement in is
>     enough.
>     Regards,
>     David.
>         -----Original Message-----
>         From: Michael Wang [mailto:mwang@tibco.com]
>         Sent: Thursday, February 14, 2002 2:57 AM
>         To: ebxml-msg@lists.oasis-open.org
>         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: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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC