ebxml-msg — archive

[System]

Chris, your discussion is about RM and DR/NRR for RM. We agreed to take DR out of the RM discussion. In your discussion you asked if this satisfied the end-to-end retry need but you didn't discussion multi-hop at all? All your examples were single hop (SMTP does not count as an IM and let's stay away from translating gateways for now). My question about allowing the Sending Party to retry (manually or automatically) has nothing to do with RM. The problem impacts RM (deliverySemantics=OnceAndOnlyOnce) only in that the Receiving Party MUST perform Idempotency. My contention is that the ability to retry is required any time there is a delivery failure. I am not breaching the issue of automatic vs. manual nor do I think we need to put that in the spec (in this we agree). I am not concerned with end-to-end RM here, except where duplicates are concerned. This issue does not revolve around IMs being reliable or not or even if they are true MSHs or not. This is end-to-end with a black box in the middle. I define TRP failure as: 1. a DFN sent to the From Party MSH (error or warning) 2. an Error Message sent to the From Party MSH 3. the lack of a properly constructed Acknowledgement Message (Ack/DR/NRR) upon request. There's probably something else but I can't think what right now. Let's take a few example use cases. - Lack of DR (when requested) (3) - If there is a network outage (1 or 3) - DFN from IM to From Party MSH (1 or 3) - NRR validation failure (3) - Lack of initial Ack (3) - Security Failure (error on Signature or Encryption) (2) - XML text corruption in transit (2) Some of these might be automatic and some will require a fix prior to retry. Lack of a DR is only one possible cause for a retry. In any of these cases, there will be a retry of the same message (same MessageId) to prevent duplicates which means Idempotency must be performed by the Receiving Party. If even one of these is valid, then end-to-end retries needs to be allowed. Regards, David Fischer Drummond Group.