ebxml-msg — archive

[System]

I agree that even the phone call is either inconclusive or impractical in some cases. Customer service at my wife's health insuror has no idea whether a claim has arrived until processing is completed. They don't enter it into the computer until then. One could conclude that reliable messaging is impossible or at best it only pushes retries down from the application to the middleware. A better approach is to design for the .999 of the cases where it does what it is supposed to do and then add some caveat about pathological cases. Delivery Failure Notification, when it is a message from the From MSG to the From software will mean what it says except in odd cases out on the wings of the distribution. Having Reliable Messaging work MOST of the time is better than not having it. 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/13/2001 11:59:00 AM To: "Dan Weinreb" <dlw@exceloncorp.com>, Martin W Sachs/Watson/IBM@IBMUS cc: <ebxml-msg@lists.oasis-open.org> Subject: RE: T2 Retry with Delivery Receipt Even a phone call does not guarantee lack of delivery -- it may come later or the administrator could miss it. Failure can never be proven. OTOH, if the administrator (or MessageStatus or end-to-end Ack) perceives a success, this should be definitive. Even for success, an end-to-end Retry may be necessary to get a required NRR (DR). Confirmation of non-delivery is not really possible (Logic 101 -- you can never prove a negative). TTL may come into play here and help resolve this but TTL is likely to be too long for time-sensitive issues. Regards, David Fischer Drummond Group.