David,
There are retries built into the RM protocol which is hop-to-hop
between adjacent ebXML MSH nodes. If there are transmission errors
between these adjacent nodes, then the RM retries address the ability
to recover from these. If it is the case that the configuration
of the retries and the interval between them is inadequate and
resulting in DFNs except in the rarest of cases, then you
increase the number and/or interval between them. You can and
should configure retries such that only in the very extreme
cases, such as nuclear winter, would there be a total failure.
As I described, if you know that the message could not have been
delivered (DFN severity=Error) then you can send a new message
with the same payload and be assured that the delivery semantics
of OnceAndOnlyOnce still apply. If you want to build in
resend/retry functionality into your implementation of an MSH,
you are free to do so. There is nothing in the specification
preventing this. The only caveat is that the message be a new
message (different MessageId).
As I also indicated, the various failure modes you describe
(Signature validation, NRR (still don't get this one), Encryption,
and corruption) also share the same characteristics with a DFN
with a severity of Error; the recipient (application) has not and will not
ever "receive" and process the message. It is therefore safe
to send a new message with the same payload without compromising
OnceAndOnlyOnce deliverySemantics and without requiring that we resort
to any change in what is currently specified.
More comments below.
Cheers,
Chris
David Fischer wrote:
>
> 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
--
See above, you are free to do so as long as it has a different MessageId.
> 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.
Yes, and guess what, the message you (re)sent had a different MessageId.
From SMTP's perspective, it is a new message. The fact that the content
of the message was the same as a previous message is unknown and irrelevant to
the SMTP protocol.
>
> David Fischer
> Drummond Group.
>
>
