Re: CPA and overrides

[christopher ferris <chris.ferris@east.sun.com>]

This is precisely my thinking on the matter as
well.

Cheers,

Chris

"Moberg, Dale" wrote:
> 
> > Hi...
> > Just wanted to comment on the conversation in yesterday's
> > conference call
> > relative to overriding the CPA.
> >
> > In the automotive industry, more companies *do not* engage in trading
> > partner agreements than do. So with that, AIAG would like to see:
> >
> > 1. Optional link to the CPA. We would like to have the
> > *option* to link
> > to/use a CPA, but we would rather it not be mandatory.
> 
> CPA is not equal to TPA, of course. But isn't modularity of usage already
> required within ebXML? That is, the pieces are supposed to be
> usable independently, right?
> 
> For example, CPPs and CPAs need not mention TRP packaging,
> security or transports. And ebXML messaging could occur without
> any CPA being exchanged (though not without some runtime stuff
> being setup...)
> 
> The CPA/CPP is after all an _exchange_ format for interoperabilty
> profile information and some runtime configuration information.
> 
> However, some of the information exchanged in a CPP/CPA at configuration
> time is made available to the run-time MSH processor. The access method to
> that
> runtime info has not been specified in any detail. The "CPAId" might, along
> with other info- From, To, Conversation, Service/Action --
> be enough to retrieve the records. I don't think anyone has for some time
> been proposing that the MSH always operate in a "stateless" manner (so that
> its behavior is totally specified by data found in the PDU).
> Or has this changed too?
> 
> > 2. Optional override of the CPA.
> >
> 
> I think the better thing to say would be to change the CPA
> or just stop using it or better avoid using it in the first place.
> 
> If you can optionally override any aspect
> on a per message basis, I think you are asking for a level
> of anarchy incompatible with interoperability... If you can
> can change anything whenever you want,
> (send PGP instead of SMIME just to
> keep the other side on their toes)
> then don't bother using a CPA!
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org
begin:vcard 
n:Ferris;Christopher 
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XML Technology Development
adr:;;One Network Drive;Burlington;Ma;01824-0903;USA
version:2.1
email;internet:chris.ferris@east.Sun.COM
title:Sr. Staff Engineer
x-mozilla-cpt:;0
fn:Christopher Ferris
end:vcard