ebxml-msg — archive

[System]

David, Please see below. Cheers, Chris David Fischer wrote: > > 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). Not at all. I gave 3 use cases, the third had a formal ebXML MSH intermediary node. I should point out that it was you who raised the EDI/INT gateway use case as a reason why you felt that end-to-end retries were a requirement. I was only building on that. > > 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). Okay, this is clearer. If a DFN is returned, there are two possible meanings implied: - the message could not possibly have made it to the To Party - the message may have made it to the To Party, there is simply no proof (Ack) I think that the speification already covers the DFN adequately with the exception of Marty's suggested change (SHOULD to SHALL to ensure that a DFN is ALWAYS genereted). The DFN has an Error severity if it is known that the message could not possibly have reached its destination. The DFN has a severity of Warning if it MAY have reached its destination but was simply unacknowledged after exhausting all retries. A retry/resend of the identical message (same MessageId) above and beyond the RM-related retries can be accomodated when the DFN was generated locally (by the original sending MSH node) with a severity of either Error or Warning. It isn't clear to me that we have defined clearly enough the means by which the source of a DFN can be determined. It is also unclear as to whether an origin MSH that cannot communicate with the endpoint actually constructs an ebXML SOAP message, or whether it can simply throw an exception or notify the "application" layer in some manner other than the creation of an ebXML SOAP message that has an ErrorList with an Error element of DFN. This needs some clarification in any event. A resend of a new message (different MessageId) with the same payload can always be safely accomodated if the severity of the DFN (generated anywhere along the message path) was Error. We can, and possibly should state this clearly in the specification, without going to the extreme of actually specifying any required MSH behaviour w/r/t a resend/retry, thus leaving it to the layer of software "above" the level of the MSH. A DFN with a severity of Warning needs further investigation IMO. Clearly, we should not encourage that a new message (same payload) be sent if the DFN severity is Warning. We could, possibly in a non-normative section, describe how the Status inquiry service can be used to determine the status of the message w/r/t the To Party. If the message has indeed not been received, then it would seem to me to be a relatively safe course of action to send a new message with the same payload, assuming that this course of action is suitable for the "application"/message (e.g. it's business ttl is still viable). It should also be noted that the likelihood of this is fairly remote. > > 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 the DR is sent reliably, then its absense is significant cause for concern. > - If there is a network outage (1 or 3) I assume that you mean 3 (DR) if the DR is sent unreliably. If sent reliably, then a network partition would result in a DFN (1) with a severity of Error which, as I stated before, can be safely accomodated by resending the original, identical message. > - DFN from IM to From Party MSH (1 or 3) See above, if severity is Error, message can be safely sent as a new message with the same payload. We can say this, but it must be clearly stated that this functionality is outside the scope of the MSH proper, but of course can be implemented as an add-on. > - NRR validation failure (3) Seems to me that this use case needs further decomposition. Do you mean that the receiving MSH failed to validate the signature of the original received message, and is therefore reporting that it will not process the message? This seems to be a case of a (2) above. In that case, sending a new message with the same payload is safe because the To Party has indicated that it will not process the message. Of course, this case also requires further investigation/intervention. If the signature is based on a certificate that has expired, or which the To party doesn't recognize as valid, then more than a simple retry is in order. If the NRR validation failure is at the sending node, then it isn't clear to me that resending the message is in order at all. If the message was mangled in transit, then clearly, something needs to be done to ensure that it never happens again! A retry gets you nowhere when there is some manner of security violation. > - Lack of initial Ack (3) Already accomodated in the spec with the RM retry protocol. > - Security Failure (error on Signature or Encryption) (2) Send a new message with the same payload. See above regarding the fact that there are more than likely bigger problems involved. > - XML text corruption in transit (2) Unless you can verify that the message wasn't mangled to begin with, a retry does little to resolve the problem. In any event, sending a new message with the same payload is always safe in this circumstance because it is known that the To Party cannot and will not process the original message. > > 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. See above, I don't think that there is need to do anything to support resending a message beyond what is already accomodated by the spec. > > Regards, > > David Fischer > Drummond Group. >