RE: Intermediary support in the 1.1 version of the MSG and CPP/A specs

[Dale Moberg <dmoberg@cyclonecommerce.com>]

Responses to Arvola's questions:

" I believe Dale is assuming that a common CPA will be used
by the From Party, the To Party, and the intermediary/intermediaries."

Well, the intermediary does not really have a CPA with a one CPA
approac

"Consider the one intermediary case,
if the intermediary's endpoints are transparently used by the From Party
and
the To Party as their own endpoints in the CPA (i.e., the transport
endpoints in the CPA all contain addresses associated with the
intermediary), then where does the intermediary find the real forwarding
addresses for the From Party and To Party? "

Out of band. Intermediary's problem. No active CPA support.
It would at least take a change in the Transport element to provide
Via support. Then we could use the real From and To endpoints
in Transport, and under Via, add the intermediaries endpoints.
That would work for a bare bones exchange of endpoint information
in a One CPA approach. For multiple intermediaries (no branches
allowed), a list of Vias under one Transport and the reversed list 
under the other.

"Clearly, there is extra
configuration information needed by the intermediary that is missing
from
the CPA." 

Dale: Agreed. The One CPA approach does not enable the intermediary to
glean
info off the CPA. If that were to be supported, we could try adding
a Via under transport, or we could move to the 3 (or more) CPA 
(bilateral decomposition) treatment.

"I also tend to agree with Marty that once you take into
consideration transport level security or if there are multiple
intermediaries, it will be unwieldy to capture all the relevant
configuration information in one CPA. 

Has anyone worked out simple examples where a separate CPA is used
between
each adjacent pair of MSH nodes? What kind of business processes have to
be
used to represent the message forwarding activities?" 

Dale: Should we pursue a BPSS-like approach to this, so that forwarding
becomes
a "pseudo" BP? If so, the Response endpoint and the Ack endpoint and
Error
endpoint for the intermediary
will need to be handled differently. We can work this out
next week if that is how Messaging approaches intermediaries. 
We do have several options to pursue, and many supporting
details to fix.

"What Service and Action
elements will be appropriate
under the Via element?"

(see previous reaction-- I think Messaging already has "special" actions
for
its Ping and Pong and Status Request and Response, so there is a
precedent for
using a MSH service for Service and Action. While the concepts of
Request
and Response may not literally apply to Forwarding, we can figure out
ways
to subsume Forwarding, with some stretching.)

" Is the existing CPP/A
element structure sufficient for this purpose?"

Nope, needs to add something as you noted above. Or are you worried
about Service, Action
and intermediaries? David B. has a worry here but I have not been able
to find 
a precise statement of what his requirement is and what motivates it.

Show up next week and we will try to assess!

We would need to walkthrough some examples with some specific
interpretation of 1. intermediaries and 2. their function  and
3. their responsibilities before we know what is needed.