Re: T2 PLEAE READ - Suggested solution to RM Issues

[Dan Weinreb <dlw@exceloncorp.com>]

   Date: Mon, 10 Sep 2001 15:40:12 -0700
   From: "Burdett, David" <david.burdett@commerceone.com>

   1. We cannot assume that everyone will be using ebXML for all nodes in a
   message path as there is a lot of legacy stuff out there. Eventually
   perhaps, but not in the short term. This means that anything that REQUIRES
   ebXML at all nodes in a message path will only have limited use.
   2. In the use case I am proposing the first hop (A to B) is using ebXML but
   the second hop (B to C) is not.

OK.  As I understand it, in this scenario A and C are conducting a
business transaction, and from A's point of view it's supposed to look
like ebXML.  So, B has to act as a protocol-translating gateway,
creating a facade in front of C that makes it look at A as if C could
actually support ebXML.

It seems to me that this "protocol-translating gateway" is a very
different animal from questions of what happens when the two ends are
genuine ebXML MS implementations and we're concerned with ebXML MS
IM's in between.  This sounds to me like a whole different problem.

   3. If C does not support a delivery receipt, then it can still work as B
   will have to report failure to A if it cannot reliably delilver the document
   to C.

If A requests a delivery receipt, then does he get one?  (This is a
question about a positive receipt, not a failure notification.)
Clearly the DR message is not generated at C, since C has never heard
of ebXML, so B has to actually generate the DR.  Clearly B should only
do this if B knows, somehow, that C for sure did receive the message.
The protocol that B and C are talking either has this ability or
doesn't.  If it doesn't, *and* ebXML requires that parties be able to
generate DR's, then the protocol-translating gateway just can't do its
job.  Either the B-C protocol can let B know that C got the message,
or ability to provide DR's must be considered optional by the ebXML MS
definition and B's image of C is as if C has an ebXML implementation
that doesn't support DR.

   4. If A requests a delivery receipt but C can't deliver it, then B would
   return a "NotSupported" error on receipt of the message from A as B knows
   that C cannot deliver the receipt.

Agreed; that's assuming it's acceptable for a party to not support delivery
receipts.

By the way, you're talking about dynamically discovering that DR is
not supported between A and C.  In general, ebXML seems to have been
more designed around doing these things statically, with a CPA or the
equivalent, than discovering them at runtime.  I don't know all the
history behind this, but it seems consonant with the whole idea of the
CPA that whether DR's are to be used or not should be pre-agreed.

(By the way, many people have said "A CPA is not required", but I've
never been sure how this works: If there is no CPA, where do those
values come from when the MSH goes to look for them?  I can see two
possibilities: (1) when there is no real CPA, there is still some kind
of implicit CA that can statically provide the same info to the MSH
that the CPA provides, e.g. rules saying that if we're using RNIF, the
values of such-and-such CPA parameters are always such-and-such.  Or,
(2) it gets negotiated at runtime, dynamically.)

-- Dan