Small point on DF RE: Intermediary support in the 1.1 version of theMSG and CPP/A specs

[Dale Moberg <dmoberg@cyclonecommerce.com>]

David Fischer writes:
"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. .."

David, 
if Option 1 gets in the running, I suggest dealing with the cascading
retry 
problem by stipulating that all retries stem from the original sender
only. The
IMs do not retry until prodded, in other words."