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>
