Re: [ebxml-msg] Reliable Messaging question

[Christopher Ferris <chris.ferris@sun.com>]

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)

Cheers,

Chris
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 4.2.3.2.4, 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 4.2.3.2.4 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
>