ebxml-msg — archive

RE: Intermediary support in the 1.1 version of the MSG and CPP/A specs

From: System
To: [email protected]
Date: Wed, 26 Sep 2001 14:09:00 -0000

Option1 does not have a retry flood if the intermediaries only forward and don't do their own retries. I agree that options 1 and 2 are almost the same (assuming that the intermediaries don't do their own retries). It seems to me that option 1 is preferable only if the intermediaries have to be aware of the ACKs coming from the next neighbor upstream. Regards, Marty ************************************************************************************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************************* "David Fischer" <[email protected]> on 09/26/2001 01:25:03 PM To: Martin W Sachs/Watson/IBM@IBMUS, "Arvola Chan" <[email protected]> cc: "christopher ferris" <[email protected]>, <[email protected]>, <[email protected]> Subject: RE: Intermediary support in the 1.1 version of the MSG and CPP/A specs Forwarding to the first IM is easy. If the From Party is not sending directly to the To Party, then the From Party simply adds a Via with another CPAId (different from the end-to-end CPA). The MSH sees a Via and instead of sending to the To+PartyId the MSH looks up a url in the CPA specified by Via+CPAId. So far, so good. The IM gets the message -- now what. If the IM can send to the To+PartyId (one IM) then everything works, what if it can't (multiple IMs)? How does the IM know where to send the next hop? This needs some serious consideration. We also need to deal with Dale's issue of backing out Acks. If the IM receives the message and sends an Ack, this does not mean the message reached the To Party. If there is a failure (DFN) later in the path, then the Ack for each previous hop should be Backed Out. I see the following options: 1. Don't send the Ack until the Ack from the next hop is received. 2. Don't send IM Acks, end-to-end Acks only. 3. Send DFN to each hop and rescind the Ack at each hop. 4. Don't bother. 5. Don't do Multi-hop. Option 1 is the Cascading Ack we discussed earlier which has the potential for a Retry Flood downstream. Option 2 effectively eliminates IM RM. It actually seems to me that option 1 and 2 are almost the same. Option 3 is quite complex. Option 4 means that an IM Ack has no meaning other than as a trace/Error tool. Regards, David Fischer Drummond Group.