Re: T2 Retry with Delivery Receipt

[Dan Weinreb <dlw@exceloncorp.com>]

   Date: Thu, 13 Sep 2001 11:48:33 -0400
   From: Christopher Ferris <chris.ferris@sun.com>

   > The only problem is that the addition of multi-hop interferes with end-to-end
   > retries (duplicates) which, as we have seen, is a fundamental functional
   > requirement under all circumstances when a Delivery Receipt is requested but not
   > received.

   You're asking for retries on top of retries. What happens when the end-to-end
   retries are exhausted and there is still no delivery receipt? Do we add retries
   of retries of retries? What happens when they fail? Do we add yet another layer?

What David is asking for is perfectly sensible *if* you your failure
model states that IM's are unreliable, e.g. that an IM might accept a
message, and then silently forget it.  In that case, the end-to-end
retries exist for a specific purpose: to harden the system against the
possibility of flaky IM's.  There would be no need to add another
layer unless there is some additional, distinct failure mode to be
taken care of.

   Why not focus on what you perceive as an omission in the spec, that an intermediary
   has certain obligations w/r/t reliable delivery. Let's address that by adding
   text that fully sets out what the responsibilities of an intermediary are
   not only w/r/t RM but w/r/t routing and any other oddities of an intermediaries
   role that is clearly distinct from that of an endpoint.

I think David's position is that we can't do that, because there are
hosts/entities out there that (a) must participate as ebXML MS IM's,
and (b) that are unreliable.  The question is whether there's a use
case demonstrating this.

   I'd like to focus on the specific use case that you cited in the call, where
   an MSH uses an EDI/INT gateway. Is there an ebXML MSH at the To Party or do they
   simply have an EDI/INT server? 

	   MSHA -> IMSHGW -> EDI/INTGW -> EDI/INTB

   In this case, how does the ebXML delivery receipt get generated? IMO, the
   EDI/INT Gateway has a responsibility to ensure that the message is safely
   delivered. How it does this is not the perview of our specification. However,
   that doesn't obviate the responsibility that the gateway intermediary node 
   assumes.

I'd call this a protocol-translating gateway, not an ebXML MS IM at
all.  I agree that the gateway has to make sure that the message is
truly delivered, and then the gateway generates the DR.  It's the
job of the protcol-translating gateway to create the illusion that
the far end is really running ebXML MS.