ebxml-msg — archive

[System]

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> > >