RE: CPA and overrides

[Scott Hinkelman <srh@us.ibm.com>]

Dale M:
> 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!
-------

I agree with Dale. Using a common configuration file means, well,
using a common configuration file (a CPA). No overrides.
As someone suggested toward, We could just use the CPAid as a pointer to
whatever to
indicate where the config data is, and recommend that an ebXML CPA be used.
If the pointer
is not there, the the message handlers 'know what to do'. Thoughts?

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



"Moberg, Dale" <Dale_Moberg@stercomm.com> on 02/23/2001 08:38:15 AM

To:   "'maw2@daimlerchrysler.com'" <maw2@daimlerchrysler.com>,
      ebxml-transport@lists.ebxml.org
cc:
Subject:  RE: CPA and overrides





> 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