RE: CPA and overrides

[Rik Drummond <rvd2@worldnet.att.net>]

maybe the way to solve this is to keep the cpa cause i think it will add a
lot of value in formal, VAN, type transfers.... and say that the cpa values
may be moved to the header with a naming convention of xmlns:(THE CPA
ELEMENT NAME).

that would let the market decide, which is best, and not a lot of tech'ies
attempting to tell the market what it needs.

this issue must be solved by early next week. if it is not i will flip a
coin to see which way it goes in our spec.... since we are out of time
completely...... rik



-----Original Message-----
From: Dick Brooks [mailto:dick@8760.com]
Sent: Friday, February 23, 2001 7:44 AM
To: rsalz@CaveoSystems.com; ebxml-transport@lists.ebxml.org;
maw2@daimlerchrysler.com
Subject: RE: CPA and overrides


I agree with Martha and Rich. Forcing a CPA/CPP module onto an MSH solution
is an unnecessary burden on those
needing simple, "direct" file transfer over a single transport, which is the
majority of implementations
in the Energy industry. The EDIINT AS2 specification made provisions for
multiple transport options by adding
a "receipt-delivery-option" header.  This header contains a URI indicating
the transport and delivery point (e.g.
http://b2b.imacompany.com/cgi-bin/ebxmlhandler or
mailto:ebxmlhandler@imacompany.com ) to send an asynchronous receipt
(acknowledgement).

CPA/CPP functionality is a nice feature for some, but it shouldn't be a
requirement for ALL. If alternate delivery channels are needed for
*acknowledgements* then I suggest a solution like that found in AS2.

Dick Brooks
http://www.8760.com/


-----Original Message-----
From: rsalz@CaveoSystems.com [mailto:rsalz@CaveoSystems.com]
Sent: Friday, February 23, 2001 7:57 AM
To: ebxml-transport@lists.ebxml.org; maw2@daimlerchrysler.com
Subject: Re: CPA and overrides


List-Unsubscribe:
 <mailto:ebxml-transport-request@lists.ebxml.org?body=unsubscribe>
List-Archive: <http://lists.ebxml.org/archives/ebxml-transport>
List-Help: <http://lists.ebxml.org/doc/email-manage.html>,
 <mailto:ebxml-transport-request@lists.ebxml.org?body=help>

As I recall the discussion of "override" from the telecon's of a couple
of weeks ago, the concern was that an MSH not be able to change the
delivery semantics that were specified in the CPA.  For example, a
UDP-based MSH could not accept a message intended for ReliableMessaging,
but then silently use BestEffort.

*IF* we put all the delivery semantics into the ebXML message header,
then this question mostly goes away, because there is no CPA involved:
it becomes a quality of implementation issue for how the business app
tells its local MSH what semantics are required *by the business
agreements.*

Requiring an MSH to have to refer to a CPA is clearly a layering violation.

	/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