Maybe I am missing something here. I thought that (1) TCP transmission
error detection is sufficient and (2) the result of a transmission error is
that TCP discards the message. If so, then a transmission error will
result in the message not being delivered to the receiving MSH. Therefore,
no acknowledgement will be returned. Therefore, normal RM retries take
place. If we trust TCP's transmission error detection, then the conditions
mentioned below (Signature validation, NRR, Encryption validation, XML
corruption)are content problems, not transmission errors, and have to be
recovered at a content level, not at the MSH level.
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 <> on 09/18/2001 02:43:34 PM
To:
ebXML Msg <>
cc:
Subject: RE: T2 Retry with Delivery Receipt
Chris,
You dismiss retry as a valid option in transmission error (Signature
validation,
NRR, Encryption validation, XML corruption) as if there is something which
can
be done to prevent such a thing. Waving your hand at a problem does not
make it
go away. The truth is that transmission errors happen constantly on the
Internet at a much higher rate than anyone likes to admit and there is
nothing
which can be done to prevent it -- except try again. Retry is the normal
first
step for ANY delivery failure situation. The question should not be "why
should
we support retry" but rather "why wouldn't we support retry".
Why would retry ever be OK at the IM level but not OK from the Sender?
Objectively, they are no different. The ONLY issue is whether an IM should
pass
a resend from the Sender. In this case, the IM is the provider and the
Sender
is the customer (the IM services the Sender). Under what extraordinary
circumstances should the service provider tell the customer "you can't do
that"?
You NEVER tell a customer no. If you do, the customer will go find a
different
service provider.
Maybe I should ask why wouldn't you allow me to retry a message if that is
my
desire? You don't sell products by telling someone what they can't do --
someone else will do it. You sell products by being flexible, not
intolerant or
autocratic. I cannot conceive of a situation where someone would not, as
the
first fix, send a retry on a delivery failure. Chris, maybe that would not
be
your first action but it is most everyone else's. I had a delivery failure
on
an eMail this morning and the first thing I tried was to send it again --
guess
what, it worked.
David Fischer
Drummond Group.
