Re: T2 Retry with Delivery Receipt

[Christopher Ferris <chris.ferris@sun.com>]

Marty,

The SMTP "intermediaries" are not ebXML MSH intermediaries
and thus there is no analogy at all. 

The whole point I make is that there isn't an unreliable
ebXML MSH intermediary involved when OnceAndOnlyOnce is
in play for a message.

Cheers,

Chris

Martin W Sachs wrote:
> 
> Sure but it is an example of how ebxml end to end RM can work through
> unreliable IMs.
> 
> *************************************************************************************
> 
> 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
> *************************************************************************************
> 
> Christopher Ferris <chris.ferris@sun.com> on 09/13/2001 01:40:58 PM
> 
> To:   Martin W Sachs/Watson/IBM@IBMUS
> cc:   Dan Weinreb <dlw@exceloncorp.com>, david@drummondgroup.com,
>       ebxml-msg@lists.oasis-open.org
> Subject:  Re: T2 Retry with Delivery Receipt
> 
> Marty,
> 
> AN SMTP node is NOT an MSH node. It is not part of the equation.
> The MSH nodes that are communication via SMTP are the ones that
> adopt the RM protocol of retries in the absence of an Acknowledgment.
> The SMTP nodes are incidental.
> 
> Cheers,
> 
> Chris
> 
> Martin W Sachs wrote:
> >
> > 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>
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;One Network Drive;Burlington;Ma;01803-0903;USA
version:2.1
email;internet:chris.ferris@east.sun.com
title:Senior Staff Engineer
fn:Christopher Ferris
end:vcard