[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Intermediary support in the 1.1 version of the MSG and CPP/A specs
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC