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 <> on 09/13/2001 01:40:58 PM
>
>
To:
Martin W Sachs/Watson/IBM@IBMUS
> cc:
Dan Weinreb <>, ,
>
>
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 <> on 09/13/2001 12:55:02 PM
> >
>
> Please respond to Dan Weinreb <>
> >
>
>
To:
>
> cc:
,
>
>
Subject: Re: T2 Retry with Delivery Receipt
> >
>
>
Date: Thu, 13 Sep 2001 11:48:33 -0400
>
>
From: Christopher Ferris <>
> >
> >
> 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:
title:Senior Staff Engineer
fn:Christopher Ferris
end:vcard
