RE: Multi-hop reliable messaging

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

Steve

I'm including ideas similar to the ones you suggest in my rework of reliable
messaging to support implicit acknowledgements and multi-hop. I hope to get
a first version of this posted to the list next week.

David

-----Original Message-----
From: Steve Hole [mailto:steve.hole@messagingdirect.com]
Sent: Thursday, November 16, 2000 8:38 AM
To: Rik Drummond
Cc: Burdett, David; MKudela@uc-council.org;
ebxml-transport@lists.ebxml.org; mona@mail2.commerceone.com
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