RE: T2 Retry with Delivery Receipt

Dan,  Let's break this into two pieces

--
Automation and Retries.  Piece One

--
Automation: The automation of Retries is actually an implementation detail.  The CPA elements are there to do this.  I believe the best (only) practical trigger is DR.  IM retries are triggered by the lack of an Acknowledgement and I believe so should end-to-end retries.  The spec already calls DR an acknowledgement message and I'm fine with that.  How this is done is not really important and I am not asking for any changes in the spec in regards to this.  Just leave the spec alone.  Piece Two (the important part)

--
Retries: The important part is the ability to retry.  Whether this happens from automated retries or from DFN (I am using this to mean a failure from an IM back to the Sending Party MSH on lack of an Ack) or strictly manual is not really relevant. The important part is that we MUST be able to recover from failure.  This does not mean the IM is unreliable.  The IM may perform its task perfectly and send the DFN back to the Sending MSH.  What then?  At some point we must retry -- whether immediately or after a fix.  I must *strongly disagree* that this retry is a new message with a new MessageId.  This will produce undectable duplicates at the Receiving MSH and thus unusable systems from the customers point of view. Even the idea of waiting for TTL to pass won't really work because TTL does not apply after the message is passed to the application.  This is Important.  We MUST allow retry of the original message or we have a broken spec in regards to multi-hop (single-hop is fine).  The fix for this is RetryCount in Via.  Regards,  David Fischer Drummond Group.