RE: T2 Retry with Delivery Receipt

[David Fischer <david@drummondgroup.com>]

Dan,

Let's break this into two pieces -- Automation and Retries.

Piece One -- Automation:
The automation of Retries is actually an implementation detail.  The CPA
elements are there to do this.  I believe the best (only) practical trigger is
DR.  IM retries are triggered by the lack of an Acknowledgement and I believe so
should end-to-end retries.  The spec already calls DR an acknowledgement message
and I'm fine with that.  How this is done is not really important and I am not
asking for any changes in the spec in regards to this.  Just leave the spec
alone.

Piece Two (the important part) -- Retries:
The important part is the ability to retry.  Whether this happens from automated
retries or from DFN (I am using this to mean a failure from an IM back to the
Sending Party MSH on lack of an Ack) or strictly manual is not really relevant.
The important part is that we MUST be able to recover from failure.  This does
not mean the IM is unreliable.  The IM may perform its task perfectly and send
the DFN back to the Sending MSH.  What then?  At some point we must retry --
whether immediately or after a fix.  I must *strongly disagree* that this retry
is a new message with a new MessageId.  This will produce undectable duplicates
at the Receiving MSH and thus unusable systems from the customers point of view.
Even the idea of waiting for TTL to pass won't really work because TTL does not
apply after the message is passed to the application.  This is Important.  We
MUST allow retry of the original message or we have a broken spec in regards to
multi-hop (single-hop is fine).  The fix for this is RetryCount in Via.

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: Dan Weinreb [mailto:dlw@exceloncorp.com]
Sent: Thursday, September 13, 2001 11:55 AM
To: chris.ferris@sun.com
Cc: david@drummondgroup.com; ebxml-msg@lists.oasis-open.org
Subject: Re: T2 Retry with Delivery Receipt


   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.

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>