[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: T2 Retry with Delivery Receipt
<df>Comments in-line</df> David Fischer Drummond Group. -----Original Message----- From: Dan Weinreb [mailto:dlw@exceloncorp.com] Sent: Wednesday, September 19, 2001 10:07 AM To: david@drummondgroup.com Cc: ebxml-msg@lists.oasis-open.org Subject: Re: T2 Retry with Delivery Receipt Date: Wed, 19 Sep 2001 09:46:21 -0500 From: "David Fischer" <david@drummondgroup.com> Very good. I agree with most of it. Thank you. One comment about check-sums. We already have an transmission error-catching mechanism called NRR. Yes, but it has several drawbacks as an error-catching mechanism. First, it's optional. Second, the error isn't detected until after the receiver might have processed the message. <df>Correct, what might we do that is better? Do we really want to do anything?</df> On the whole, I think this is very good. The point is that there are some scenarios which would require a retry. But I prefer to phrase the question differently -- why would an IM *ever* stop a retry from the end? It is not the job of an IM to tell the ends what they may or may not send. Since it is an easy thing to differentiate between an IM retry and an end retry, its not "why would we" but rather "why wouldn't we"? Of course an IM should never stop an end-to-end retry; of course if the protocol allows for end-to-end retry, there would be an easy and well-defined way to differentiate. The proposed "retry count" is one way to do it. <df>Agreed. Is there another way you might prefer?</df>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC