RE: CPA and overrides

[Doug Bunting <Doug@ariba.com>]

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.

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

    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