ebxml-msg — archive

[System]

NRR is a non-repudiation function. It is not intended as a transmission error detector. Someone will have to make a convincing case that TCP is not sufficient for detecting transmission errors. Regards, Marty ************************************************************************************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************************* David Fischer <david@drummondgroup.com> on 09/19/2001 10:46:21 AM To: Dan Weinreb <dlw@exceloncorp.com> cc: ebxml-msg@lists.oasis-open.org Subject: RE: T2 Retry with Delivery Receipt Very good. I agree with most of it. One comment about check-sums. We already have an transmission error-catching mechanism called NRR. 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"? This may all be moot since built-in problems with multi-hop (like not allowing end-to-end retries) could force IMs out of the picture. I'd rather not, but . . . ? Regards, David Fischer Drummond Group.