RE: CPA and overrides

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

The CPA optional element is in context to negotiation or agreeing prior to
runtime use.
Let me add a third meaning: CPP can over-ride security abstractions
(confidential) in their
CPP for claiming what the actually support (I can play that role but no
security). Thats an
over-ride. ..........Moving on, the issue is at the MSH runtime.....

signing out.

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



Martin W Sachs/Watson/IBM@IBMUS on 02/23/2001 12:20:25 PM

To:   Scott Hinkelman/Austin/IBM@IBMUS
cc:   "Moberg, Dale" <Dale_Moberg@stercomm.com>,
      "'maw2@daimlerchrysler.com'" <maw2@daimlerchrysler.com>,
      ebxml-transport@lists.ebxml.org
Subject:  RE: CPA and overrides




Maybe my problem is the two different meanings of override.  The CPA has an
optional Override element which is specifically for substituting a
different delivery channel for the one defined for most messages.  This is
neither anarchy nor an interoperability issue.  It simply allows two
parties to agree to use different delivery channels for different types of
messages.  It is specifically inspired by RosettaNet, some of whose PIPs
provide for, for example, a request via HTTP and the response via SMTP.

Unilateral overrides (in the more generic sense) by one party without prior
agreement with the other party are indeed anarchy and an interoperability
disaster.

Regards,
Marty

*************************************************************************************


Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************




Scott Hinkelman/Austin/IBM@IBMUS on 02/23/2001 12:33:06 PM

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



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



------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org




------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org