OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[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]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC