Re: T2 PLEAE READ - Suggested solution to RM Issues

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

Comments below.

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/11/2001 10:25:54 AM

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

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   david.burdett@commerceone.com, chris.ferris@east.sun.com,
      arvola@tibco.com, ebxml-msg@lists.oasis-open.org
Subject:  Re: T2 PLEAE READ - Suggested solution to RM Issues



   Date: Mon, 10 Sep 2001 22:19:52 -0400
   From: "Martin W Sachs" <mwsachs@us.ibm.com>

   I agree with your comments on the case described in your posting (below)
   but it does call into question my previous posting. Consider this:

      A----B----C----D

   Clearly, A and D have to communicate end to end via ebXML messaging, CPA
   (virtual or real), and BPSS (virtual or real).

I agree.

   The problem is that there is nothing requiring that the link between B
and
   C be an ebXML path.  Therefore both of our previous comments that all IM
   nodes must have two MSHs are not correct.  In the simplest case (dumb
store
   and forward only), we can consider the combination of B and C as a
single
   intermediary ("virtual ebXML IM") with what goes on between them an
   internal matter that is outside the scope of ebXML.  It is thus even
more
   important that the spec clearly state its assumptions about the
   intermediary functions above the level of the MSH including some words
   about the case where there is a non-ebXML link in the path between two
   intermediaries.

I agree strongly about "clearly state its assumptions".


Perhaps a more useful analogy might be to the way the original Arpanet
worked.  The Arpanet was based around a "subnetwork" of
special-purpose computers called IMPs (interface message processors).
Every host was attached to an IMP via an Arpanet-standard hardware
interface.  Each IMP talked to up to four (or something much like
that) other IMPs, over dedicated 56Kbaud phone lines, forming a
not-fully-connected graph.

There were three protocols going on:
- IMP-IMP
- Host-IMP
- Host-Host

The IMP-IMP protocol was not advertised to those of us out at the
hosts.  It was entirely the IMPs own business how they got messages
from one place to another, and the Arpanet authorities (e.g. BBN) were
free to change that at any time.

The Host-IMP protocol let a host give commands to an IMP, particularly
"please take this byte-string and send it to host N".  As far as the
host-IMP and IMP-IMP protocols were concerned, the byte-string saw
opaque (an uninterpreted BLOB).  The Host-IMP protocol controlled
things like flow control (the IMP can't accept that byte-string now
because its buffers are full) and established a meaningful concept of
host address.

At a lower layer, a host knew about its own IMP; at a higher layer, a
host knew about the other host.  A host didn't know anything at all
about other IMPs.

So one way to look at your A - B - C - D example is as an analogy,
thinking of B and C as playing the role of IMP's.  A tells B, here is
a message, don't worry about its business content since that's D's
business, just get this message through to D.  The A - B communication
is like the host-IMP protocol; the A - D communication is like
host-to-host protocol; the B - C communication is like IMP-IMP
protocol.

MWS:  Actually, this is the inverse of my example.  If B and C are
the IMPs, the B-C link is the ebXML link and the A-B and C-D links are
however the IMPs are connected to the hosts.

MWS:  We don't actually have to go back to ARPANET.  The same thing
goes on right underneath ebXML, in the IP layer, where the routers and DNSs
are crucial elements in the path but don't explicitly appear in the
IP spec.

The ebXML MS spec would be addressed to the person programming A.  It
would specify two things: how A should talk to B (a la host-IMP), and
how A should talk to D (a la host-host).  It would not say anything
about how B talks to C; like the IMP-IMP protocol, this is not
advertised to the people programming endpoints like A, especially
because, as you point out, there might be *many* different protocols
for the B's of the the world to talk to the C's of the world.

MWS:  As you saw above, my view is exactly the opposite.  The network
protocol is the IMP-IMP protocol and what goes on between the host and
the IMP is sort of internal to the host.

The part of the MS spec that talked about A - B communication would
talk about things like using HTTP versus SMTP, and would not talk
about things like services and actions.  The part that talked about A
- D would be exactly the opposite.

It seems to me that if the ebXMl MS Spec could be more clearly
separated into these two layers, it would become much more clear why
the MS Sec does not venture to prescribe how B talks to C.

-- Dan