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

["Hayes, Brian" <Brian.Hayes@Commerceone.com>]

> "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. 

Brian: When my company joins an e-marketplace, the e-marketplace will know
my actual addresses of my services in which to route messages to.  The party
sending me a message only needs to know my logical addresses and the only
acutal ("physical") address it needs to know is either that of my
e-marketplace or some other e-martketplace (that is part of that is in a
larger federation of e-marketplaces [dare I use the term "Global Trading
Web"?]).  The directory look-up process  (DNS deja-vu ???) tells the
e-marketplace router where to send the message next.  When I register my
services in a trading partner directory of an e-marketplace, I will register
my actual/physical addresseses of those services (perhaps using a CPP/CPA or
CPP/CPA-like thing).  However, when other services or parties look-up my
actual address, they will get my e-marketplace's address.

Brian: When I negotiat my CPAs, I should give my e-marketplace's
address(es); otherwise, I am defeating one or more of the reasons I have
joined that e-marketplace.

> ... 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.

Brian: I see no reason to support a Via information (if I am understanding
it correctly).  This should be (or atleast have the option of being)
completely abstracted or hidden at the CPA level.  I suppose if you were
connected to more than one e-marketplace, this might be an issue.

> Dale: Should we pursue a BPSS-like approach to this, so that 
> forwarding becomes a "pseudo" BP? ...

Brian: Well "BPSS-like" and "pseudo BP" certainly qualify this approach!
The routing/forwarding services are not business services so this approach
could only be BPSS-like and the information should never appear in a BPSS.
So, does this mean that in the CPA (and CPPs?) that there might be the
specification of message level choreography?  In any case, I recommend that
we allow for intermediaries without requiring the specification of Via
information or similar information.  

Best regards,
Brian