[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: CPA and overrides
David
You asked ...
>>>How can we have a CPA w/o a formal agreement?<<<
I think this is quite simple. We include in the header, just the information
that is needed to send a message, or alternatively have a transport/delivery
channel level CPA that is independent of the business process whose id is
contained in an element in the header that can change with each hop.
You make a good point about decisions being made in the room with half the
delegates out on sub-team assignments. IMO, we should only make "BIG"
decisions like tying the TRP spec with an umbilical cord to the CPA spec on
the email list after proper discusion. After all, not everyone can get to
every F2F meeting.
I also think that tying it too tightly to the CPA spec is high risk as I for
one, have not had the bandwidth to properly review it. IMO the TRP spec is
about transporting messages and not the business process that goes with it.
The CPP/CPA spec "munges" the too together in a way that cannot be
separated. This is equivalent to reuqiring FedEx to understand the business
process that the documents they are transporting are part of.
David
-----Original Message-----
From: David Fischer [mailto:david@drummondgroup.com]
Sent: Monday, February 26, 2001 7:32 AM
To: Ralph Berwanger; Maryann Hondo; Dick Brooks
Cc: ebxml-transport@lists.ebxml.org
Subject: RE: CPA and overrides
As for the issue being closed, this decision was made with half the room out
on sub-team assignments. Many of us were quite concerned when we returned
and found this vote had been taken without everyone present.
As for overriding or not, the problem is the number of things in the CPA.
If everything gets put in the CPA, then we are locked down tight. If there
are only defaults or low level fields in the CPA, then there might be more
functionality. For instance, what if the CPA says everything must be signed
but for this one transaction, I also want to add encryption? I am hearing
that I CANNOT request this on the fly and I have to go to the trouble of
creating another CPA "profile" (at both ends) just to request encryption. I
am not asking to be able to countermand security, rather I want the ability
to enhance it. What about the case of a once-and-only-once transaction
between previously unknown Trading Partners? It will take longer to set up
the CPA than to send the transaction. This is totally unnecessary. There
may be many cases where there is no formal agreement between endpoints.
This is especially true when the method of payment is by cashiers-check,
money-order, VISA, MasterCard, etc. In these cases, there is an agreement
between a bank and each entity but there is no agreement end-to-end. How
can we have a CPA w/o a formal agreement?
As for security, the hardest part of setting up a transaction is trading
certificates. Even this is not difficult since the certificate can actually
be included as a bodypart of the message (if it is from a public CA --
Verisign, Cybertrust, etc.). This can truly be accomplished on-the-fly if
only we do not have the burdensome legal hassle of creating this bloated
entity we call a CPA (it was not always so -- there was a time when it was
leaner).
IMHO, having a default set of parameters in a CPA, is fantastic. Having to
create a profile of more than just typing in the TO, is insane -- no one
will buy this. We are supposed to be building this for the SMEs and there
is NO WAY they will create a full matrix (each TP with each other TP) of
legal Trading Partner agreements. There could be thousands, millions of
such agreements.
We must provide a default CPA and we MUST allow some form of override.
David Fischer
Drummond Group
-----Original Message-----
From: Ralph Berwanger [mailto:rberwanger@bTrade.com]
Sent: Friday, February 23, 2001 9:17 AM
To: Maryann Hondo; Dick Brooks
Cc: ebxml-transport@lists.ebxml.org
Subject: RE: CPA and overrides
Mary Ann,
I agree with you and stated this same position during the TRP
meetings in Vancouver. During those meetings, we agreed that the MSH
COULD NOT override values in the CPA. I thought that this issue was
closed.
The issue remaining is must certain content of the CPA be
communicated inside of the ebXML Header? Will intermediate MSH need the
information to ensure compliance with the CPA? And if the first two
questions result in 'YES', then what information is needed? It is not
reasonable to assume that the entire CPA would be sent, for that matter
it is not reasonable to assume that all values related to the MSH would
be sent.
I think that I started this when I pointed out that we have
moved all of the attributes of the QualityOfServiceInto element into the
Reliable Messaging portion of the specification. The specification
states that the values are in the CPA and that the CPA cannot be
over-ridden. I asked, "Do we need to send the QualityOfServiceInfo
element?" The group seemed to accept the idea that the element was
still needed and that perhaps additional attributes need to identified
for the element.
Ralph Berwanger
-----Original Message-----
From: Maryann Hondo [mailto:mhondo@us.ibm.com]
Sent: Friday, February 23, 2001 8:17 AM
To: Dick Brooks
Cc: rsalz@CaveoSystems.com; ebxml-transport@lists.ebxml.org;
maw2@daimlerchrysler.com
Subject: RE: CPA and overrides
Am I the only one who is concerned about this from a security view?
if we allow for "overrides" .....what is the model of who overrides
what?
can i override the "to" part or the "from" part (particularly if i want
to
muck up the works of my
competition a bit) can i "override" the https protocol with http? and
what
about "intermediaries"?
are they allowed to "override" things?
how does as2 provide for this type of override? is this ok? is it up to
the
receiving
app to determine if the transaction came over a secure channel? whose
liability is it
if the sender sends data over an insecure link when a secure link was
agreed to and
some information is "stolen"? are these issues addressed in as2?
i could see defining a default which is used instead of a cpp/cpa or if
there is no cpa referenced,
but i would want to know how the security piece was agreed to by both
parties and how it is possible to
verify that the correct mechanism was used.
Maryann
Dick Brooks <dick@8760.com> on 02/23/2001 08:44:19 AM
To: rsalz@CaveoSystems.com, ebxml-transport@lists.ebxml.org,
maw2@daimlerchrysler.com
cc:
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
------------------------------------------------------------------
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC