OASIS Open Mailing List Archives  ·  All Lists  ·  ebxml-msg  ·  2001-09

ebxml-msg — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

Re: T2 Retry with Delivery Receipt


+1 TCP barring a MITM attack ensures that there is lossless transmission of the message between the TCP endpoints of the message is not "received". Cheers, Chris Martin W Sachs wrote: > > You are still postulating that there are transmission errors that won't be > caught by either TCP or the underlying physical transport. You need to > make a convincing case that the can happen. > > 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" <[email protected]> on 09/19/2001 10:43:42 PM > > To: Martin W Sachs/Watson/IBM@IBMUS > cc: "Dan Weinreb" <[email protected]>, <[email protected]> > Subject: RE: T2 Retry with Delivery Receipt > > Actually NRR is exactly for making sure that the message arrived intact, > either > as a protection from transmission failures or from security breaches (e.g. > man-in-the-middle attack). It might be pretty bad if I ordered 2 items and > there was a transmission failure and it got changed to 1,000,002 (actually > it > would be more binary than that). The signature assures the To Party that > it did > not change and NRR assures back to the From Party that it did not change > (round > trip). > > David Fischer > Drummond Group. > >

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]