[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Multi-hop reliable messaging
On Thu, 16 Nov 2000 04:19:37 -0600 Rik Drummond <rvd2@worldnet.att.net> wrote: > we made some major progress on allowing the ebxml mhs to connect to workflow > in the meeting last week. most people don't seem to understand the > differences between workflow and routing at this time. this will be resolved > over the next few months. it is interesting that the ack delivered from the > mhs to show it was received by the mhs is like and email delivery receipt > and that the ack you are discussing showing the workflow system or another > application is exactly like the email (rfc822) read receipt. we implemented > a tenitive delivery receipt last week. it looks to me that we will have to > implement a read receipt type ack later. i have contacted the workflow > coalition about tying their stuff into our stuff. positive first response. i > will be working that as we go forward.... best regards, rik Actually, this was something that I was going to ask about earlier, but thought I would wait. There is an obvious parallel between the routing ackknowledgements and the underlying facilities provided in the SMTP/e-mail transport. Has there been any discussion at all about trying to incorporate that support into the reliability model in the e-mail transport binding? Specifically, there are useful information states provided by DSN responses, particularly for failed message delivery. We find that, on average, failed delivery responses are returned in the Internet in about 5 seconds -- not bad actually. If you know that a message failed to be delivered, presumably you could use this information immediately to prevent continued retry attempts in the XML reliable-message layer. In the case of DELAYED DSN responses, retry attempts will also very likely be delayed and providing the DELAY information to the reliable-message layer would prevent multiple redundant retries and/or provide information to time the transaction out entirely. In any case, communicating the data for failed/delayed delivery back up through the interface would be very useful (essential?) for diagnostic purposes. Cheers. --- Steve Hole Chief Technical Officer Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC