Marty,
I mostly agree. I certainly agree from the receiving end's
perspective.
TCP transmission errors are only detectable at the receiving
end, not the sending end unless the socket is closed before
the sending end has completed streaming a message to the socket
in which case it can know that the message will not be
received.
TCP also provides for assurance that the message bits are
not corrupted in transmission through the use of checksums.
Any corruption at the content level has to happen somewhere
above the TCP layer of the stack.
The errors cited below are either MSH level or application
(as in the case of NRR) level errors which result in an
error being sent back to the sender of the message. These
should (MUST?) indicate that the receiver will not ever
process the message.
I think that the argument that while an error might be sent
to the sender, that the message might still be processed
is spurious. We shouldn't have to consider this. An error
should (MUST?) represent a failure to process a message.
Only then can you hope to build upon a solid foundation.
If an error is nothing more than informative, (I couldn't
validate the signature but I'm going to process the message
anyway) then it should be reported as such. If the case
is that the message will be processed anyway, in light of some
manner of fault, then no retry is necessary in the first
place.
Cheers,
Chris
Martin W Sachs wrote:
>
> 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.
>
>
