Re: T2 Retry with Delivery Receipt

[Martin W Sachs <mwsachs@us.ibm.com>]

Re:  "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."

There is one major use case, which is SMTP.  SMTP intermediate nodes are
notoriously unreliable and only acknowledge to the previous node so a
sender has no idea whether the message got to its destination.  ebXML on
top of SMTP is one of the major reasons for having ebXML reliable messaging
and only end to end reliable messaging helps with SMTP.  I don't know if
there is a use case for ebXML unreliable intermediaries but if there is,
end to end RM is the answer.

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
*************************************************************************************



Dan Weinreb <dlw@exceloncorp.com> on 09/13/2001 12:55:02 PM

Please respond to Dan Weinreb <dlw@exceloncorp.com>

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>