Re: T2 PLEAE READ - Suggested solution to RM Issues

[Dan Weinreb <dlw@exceloncorp.com>]

   Date: Fri, 07 Sep 2001 16:12:01 -0700
   From: "Burdett, David" <david.burdett@commerceone.com>

   From: David Fischer [mailto:david@drummondgroup.com]
   Sent: Friday, September 07, 2001 3:50 PM


   As we have discussed before, requiring RM at every node actually presents
   the
   possibility of a permanent block in a delivery chain should some IM not
   support.
   We cannot REQUIRE RM thus we cannot guarantee that the message will arrive,
   thus
   we MUST allow some other mechanism to notify the original sender of success
   (or
   failure -- failure can be defined as the lack of success since even if the
   message arrived, the loss of the DR is still a failure).  Since RM cannot be
   required then we must allow the Sender to retry.
   <db>I agree that ebXML RM cannot be required everywhere.</db>

I don't understand why you're saying this.  Let me (try to) take
Chris's position: that reliability means once-and-only-once [1].  The
message moves from one ebXML MSH to another ebXML MSH.  It is
reasonable to assume that an ebXML MSH contains a working
implementation of the ebXML Message Service protocol.  So every MSH is
capable of participating in the ebXML reliable messaging scheme.

In this point of view, what's going on is *not* analogous to TCP over
IP.  We do *not* view the IM's as primitive, unreliable beasts capable
of dropping messages forever without telling anybody that they did so.
Rather, we consider IM's to be full-fledged members of the ebXML MSH
community, just as trustworthy as the From MSH and To MSH.  There's no
problem of a "permanent block", in this view, because all IM's support
reliable messaging, by definition, since to be an IM means to support
the ebXML MS protocol in all its glory.  To put it contrapositively,
any entity on the network that doesn't support ebXML MS is not
considered to be an IM and is not treated as one.

(One might additionally argue that if you are interested in unreliable
store-and-forwarding, you should leave that to the underlying
communications layer: send the ebXML message via email and let the
SMTP servers act as unreliable store-and-forward agents.  The world
already has mailers; there is no need for ebXML MS to re-create this
same mailer functionality at a higher level.)

Is there some important reason why nodes that are not capable of ebXML
reliable messaging need to be treated as IM's?

-- Dan

[1] That is, if the From application asks the From MSH to deliver a
message, then either the To MSH will deliver the message exactly once
to the To Application, or else the To application will never receive
the message and the From Application will be informed by the From MSH
that the delivery failed.  This is the definition of "reliable" that
Chris seems to be using, if I understand him correctly.