RE: CPA and overrides

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

The hangup on optionality is the first quoted paragraph:

   The REQUIRED CPAId element is a string that identifies the Collaboration
   Protocol Agreement (CPA) that governs the processing of the message.
   The
   identifier MUST be unique within the domain of the names chosen by the
   Parties.

As I recall, this paragraph is the TRP's doing, not the TP team's doing. I
argued for the CPAId to contain two subelements, one for each party, that
contains locally meaningful information such as a pointer to the local
configuration that may or may not be derived from a CPA.  Once the first
pair of messages have been exchanged, the message header contains both
parties' pointer and each uses the one that belongs to it when it receives
a message.  Were that the definition, the parties would be free to use a
CPA or otherwise define their configuration information.

Making CPAId optional is NOT the answer because without it, some other
message header element would have to be provided so that a receiving Party
can get to the information it needs to route and process the message.

Changes in this area will break other areas.  This needs to be very
carefully thought out before doing anything.

I suspect that this is far below the cut level for issues that MUST be
settled before Vienna (read that, Mar. 19)

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



maw2@daimlerchrysler.com on 02/27/2001 06:51:46 AM

To:   "Burdett, David" <david.burdett@commerceone.com>
cc:   ebxml-transport@lists.ebxml.org
Subject:  RE: CPA and overrides




Thank you David!!!

Just as a suggestion - if the CPA is truly optional, let's say it in those
words so that there is no confusion one way or the other.

Martha




"Burdett, David" <david.burdett@commerceone.com> on 02/26/2001 04:37:59 PM

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

Subject:  RE: CPA and overrides


If the CPA is truly optional then we need to update the spec to reflect
this
as now it suggests that it is required, for example section 8.4.2 which
currently says ...

>>>
The REQUIRED CPAId element is a string that identifies the Collaboration
Protocol Agreement (CPA) that governs the processing of the message.  The
identifier MUST be unique within the domain of the names chosen by the
Parties.

A Party that receives the message, must be able to resolve the CPAId to the
CPA instance as information in the CPA is used, for example, by Reliable
Messaging (see section 10). It is therefore RECOMMENDED that the CPAId is a
URI.
<<<

How about re-phrasing this as follows ...
>>>The REQUIRE CPAId element is a string that identifies the parameters
that
control the exchange of messages between the parties. The CPAId MUST be
unique within the From and To Party Ids. The CPAId MAY reference an
instance
of a CPA as defined in the CPA/CPP specification see the ebXML
Collaboration
Protocol Profile and Agreement Specification.
<<<

Thoughts?

David
-----Original Message-----
From: David Fischer [mailto:david@drummondgroup.com]
Sent: Monday, February 26, 2001 12:10 PM
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





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