RE: reliable messaging - hop by hop

["Burdett, David" <david.burdett@commerceone.com>]

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>