Re: T2 Retry with Delivery Receipt

From
System
Date
2001-09-18T18:14:00+00:00
ID
Thread
Re: T2 Retry with Delivery Receipt
David,

I specifically stated that you CAN send the SAME message (as long as it
has a NEW MessageId) when you KNOW that the message has not been delivered
for whatever reason because you KNOW that the original message will NEVER be
processed by the ultimate recipient (the To Party's application). It is not
necessary that the MessageId be the same if there is no possibility that
the message will have ever been received/processed.

By insisting that you be able to send the IDENTICAL message (same MessageId),
you are making the problem more complicated than it needs to be (such as
addition of a RetryCount element and associated if/then/else processing
that would need to be supported by all nodes).

You cited a bunch of use cases such as signature validation failure, decryption
failure, XML corruption, NRR validation failure (you still haven't elaborated
on this one) and more, which IMO would require that a DIFFERENT message be
sent (e.g. use the right set of certificate keys, choose a message path
that won't corrupt the message in transit, etc.). I am assuming that
these failures you cite are reported by either an intermediary or the
To Party MSH node. That being the case, they reflect an inability or
unwillingness to EVER process the message they received. Why then is
there a requirement that the MessageId be the same on a "retry" as on
the original message?

I am trying to keep things as simple as possible. I do not want to see
a different set of rules for different MSHs (sometimes you feel like
a nut, sometimes you don't...).

Cheers,

Chris

David Fischer wrote:
>
> Chris,
>
> You didn't answer my question.  Why would you ever NOT allow a resend from the
> Sender?  Why would an IM *ever* stop a message from the Sender?  The Sender, for
> obvious reasons, wants to send the SAME message with the SAME MessageId.  This
> is not my eMail account, these are financial/business transactions that MUST NOT
> be received/processed twice.  No matter what the reason for the retry, there is
> never a time when an IM should stop a message from the From Party MSH.  It is
> not the business of the IM to decide what may or may not transpire between the
> From Party and To Party.  This is a different layer -- i.e. stopping the message
> would be a layering violation.
>
> "I don't want to" is not a valid reason.  "It's too complicated" is almost as
> bad (how hard is it to concatenate two strings?).  We can allow retries, Chris
> just doesn't want to.  Why?
>
> What I am suggesting by adding RetryCount is to make the MessageId of the lower
> layer different from the MessageId of the higher layer.
>
>
MessageId(lower) = MessageId(higher) + RetryCount
>
> There is nothing hard here -- although I am willing/trying to explore this for
> potential problems.
>
> David Fischer
> Drummond Group.
>
> <df>more comments in-line</df>
>
>