[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: reliable messaging - hop by hop
I think that we should define the signed NRR as being sent by the To Party MSH and not require that the application has previously been notified. The issue is that there may be further stores and queues between the To Party MSH and the actual application that prevent the To Party MSH from EVER knowing if the application received it. So how about this as the definition for the Delivery Receipt ... "The Delivery Receipt is a message sent by the To Party MSH back to the sender of the original message that indicates that the To Party MSH has received the message and will forward it to the appropriate To Party process or application." The other alternative would be to provide two variations of the Delivery Receipt, one which indicated that the To Party MSH had received and the second tha the To Party Application had been notified of the message, but I don't really want to go there as it is definitely additional functionality. I actually think that the second one is really an application level acknowledgement, David -----Original Message----- From: Dan Weinreb [mailto:dlw@exceloncorp.com] Sent: Wednesday, August 29, 2001 9:35 PM To: mwsachs@us.ibm.com Cc: david@drummondgroup.com; chris.ferris@east.sun.com; ebxml-msg@lists.oasis-open.org Subject: Re: reliable messaging - hop by hop Date: Wed, 29 Aug 2001 15:34:37 -0400 From: Martin W Sachs <mwsachs@us.ibm.com> MWS: This is one of the really sticky points about time-to-live. One possibility is that once the application is made aware of the presence of a given message in the persistent store, that message shall not be deleted except by the application. Yes, you're right. Once the message has reached persistent storage at the To Party MSH, there's no longer any reason to worry about time-to-live. If the signed NRR is returned only when the To application is made aware of the message, that should take care of this problem except that it then isn't clear what the value of time-to-live is. Its value is for duplicate elimination, so that a receiver is free to garbage-collect this message ID from its persistent table of message ID's. Once the message has arrived at the To MSH and at arrival time found to not be a duplicate, we don't have to worry about expiring it. OK, no problem then. "Never mind." ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC