RE: CPA and overrides

[Martin W Sachs <mwsachs@us.ibm.com>]

Doug,

See my comments in line below.

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



Doug Bunting <Doug@ariba.com> on 02/26/2001 04:28:22 PM

To:   "'david@drummondgroup.com'" <david@drummondgroup.com>, "ebXML
      Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
cc:
Subject:  RE: CPA and overrides



A couple of clarifications and questions:
- In TRP, the CPAId is not optional at all.  If that doesn't mesh with what
the CPA group is doing, we have a disconnect which should be addressed
through conversations between the groups.  See my PS below for a
suggestion.

MWS:  I think that the problem here is that a long time ago, it was decided
in discussions in both TRP and TP that the value of the CPAId should be
global
to both parties.  That implies that it references a single document
somewhere.
The CPAId is defined in the CPA and passed in the message headers.  In the
CPA spec, it does say that each Party MAY associate local configuration
information with this identifier.

- We're still getting into a question about conformance to the CPA, if any:
If the ebXML Header document includes some values taken from the CPA and
also references that CPA, what should a receiving MSH do in the case of
conflicting values?

MWS:  ...and if there is no CPA, then both parties have to independently
configure their middleware to do business with each other.  It seems
to me that the no-CPA case has a much greater exposure to conflicting
values than the CPA case.

As documented elsewhere in this group, we can't require
a specific behaviour since some companies, industries and business
processes
require or allow overrides of an agreed technical integration framework.

- One of our later decisions in Vancouver was to remove the ErrorURI from
our specification.  It shouldn't be in the list below.

thanx,
     doug

PS. In a separate thorough review of the Reliable Messaging chapter, I had
called out the following:
To remove one of the links between TRP and TP, add text allowing these
parameters to appear in any format that may serve as the configuration file
for a MSH implementation.  These specific parameters describe the logical
content of a configuration file and not a specific format for that
information nor a specific list of names and values.  How about:

    The term 'the CPA' refers to the set of configuration information a
sender and receiver have accepted.  The CPAId element in the ebXML Header
document references this information.  The configuration parameters may
appear in any format, including an ebXML CPA document residing at one
party's site or in a common registry.  Local storage of different formats
for this information and hard-coding its values are possible alternatives.

MWS:  As I said above, this is perfectly reasonable.  The only catch is
the ancient decision which TRP particpated in if not dominated,
that the value of the CPAId
in the message header has to be meaningful to both parties.

    Further, this section describes the logical requirements for the
portion of a CPA controlling the actions of a MSH implementation.  The
specific names, values and semantics listed here are not required of any
MSH.

Some portion of this text may also appear with the definition of the CPAId
element earlier in the overall document.

-----Original Message-----
From: David Fischer [mailto:david@drummondgroup.com]
Sent: February 26, 2001 12:10
To: ebXML Transport (E-mail)
Subject: RE: CPA and overrides

I would like to withdraw my objection to "No CPA Override" since I have
been
informed by one of the CPA authors that having a CPA is optional.  Since
ebXML TRP can work without a CPA then the override discussion is
meaningless.

I would like to second David Burdett's enunciation of header elements.
Since CPA is optional, it is important we have all the working elements in
the headers -- not only in the CPA.  We need to reexamine the spec since it
certainly appears to me there are dependencies.

Best Regards,

David Fischer
Drummond Group

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Monday, February 26, 2001 10:32 AM
To: 'david@drummondgroup.com'; Rich Salz
Cc: Ralph Berwanger; Maryann Hondo; Dick Brooks;
ebxml-transport@lists.ebxml.org
Subject: RE: CPA and overrides

So do I and I think the elements that need to go in the header are the
following ...
1. Parameters that apply to all hops:
- deliverySemantics
- messageOrderSemantics
- deliveryReceiptRequested
2. Parameters that apply to an indivual hop:
- syncReplyMode (or whatever it gets renamed as - Prasad?)
- errorURI
- reliableMessagingMethod
- AckRequeted (was IntermediateAckRequested)

Does everyone agree?

David

-----Original Message-----
From: David Fischer [mailto:david@drummondgroup.com]
Sent: Monday, February 26, 2001 8:00 AM
To: Rich Salz
Cc: Ralph Berwanger; Maryann Hondo; Dick Brooks;
ebxml-transport@lists.ebxml.org
Subject: RE: CPA and overrides

Completely Agree!

David Fischer
Drummond Group

-----Original Message-----
From: rsalz@zolera.com [mailto:rsalz@zolera.com]On Behalf Of Rich Salz
Sent: Monday, February 26, 2001 10:51 AM
To: david@drummondgroup.com
Cc: Ralph Berwanger; Maryann Hondo; Dick Brooks;
ebxml-transport@lists.ebxml.org
Subject: Re: CPA and overrides

If the ebXMLHeader element completely described the requested delivery
semantics, then override becomes a matter left to the business logic and
local configuration, since an MSH will never actually need to refer to
the CPA.

We could then remain silent on that matter, and move on to other topics.
     /r$


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