OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: CPA and overrides

We need to curtail this discussion in an attempt to move towards closure.
The combined questions we should answer:
* Do we need to be more general in our description of the CPAId and the CPA
parameters discussed in the Reliable Messaging chapter?  This would loosen
our ties to a specific CPA format and move things to more explicitly
encapsulate Chris' suggestion that a CPA is simply a configuration file
stored by a MSH in whatever format is appropriate.  (A ebXML CPA document is
one way that configuration file could be negotiated and transported between
MSH instances.)

* Should we explicitly copy some of the configuration information from our
(conceptual) CPA into the header of a TRP-compliant message?  This is both a
performance issue (avoiding lookups) and a security issue (allowing the
sender to drive intermediaries and destination systems without prior
agreement).  I agree with the general sentiment that a negotiated agreement
should not be overridden on a per document basis.  My primary concern is
around agreements that provide certain per message options to the sender.
I'd rather have parameters often left up to the sender (a set that's unclear
at this point) explicitly in the header.  At the least, a specific set of
parameters must be identified by the header.

* Should the CPAId be optional in the message header?  Alternatively, do we
need to define a predetermined set of parameters identified by specific
CPAId values?

* Is the CPA's implicit binding of business process information and
technical details appropriate for all uses within the MSH?  Dave's issue
about adding something like a CPAId to a "next actor" set of fields in the
header goes right to this point.  The next actor may be implementing a
technical service that's somewhat orthogonal to the business process enabled
by that service.  Nonetheless, any intermediary is going to have a business
relationship (even if it is a default, one time implicit agreement) with
their immediate neighbours on the chain.


-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: February 23, 2001 09:54
To: maw2@daimlerchrysler.com
Cc: ebxml-transport@lists.ebxml.org
Subject: Re: CPA and overrides


First, whether you use the CPA or not (or it is optional) is entirely up to
the middleware that you buy to support your system.

Second, the override element is already optional.



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

maw2@daimlerchrysler.com on 02/23/2001 07:31:10 AM

To:   ebxml-transport@lists.ebxml.org
Subject:  CPA and overrides

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.
2. Optional override of the 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC