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.