[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: T2 The answer isn't always "you need a CPA" was RE: T2 PLEASE READ - Suggested Change - add "From" Service and Ac tionto the header
David, (I think I am repeating myself here). With our without a CPA, two parties doing business have to share certain configuration information in order to do the business. They can express the sharing in a CPA or they can exchange information person to person and then separately put it into their systems. Certainly, there are cases where a relatively small amount of information has to be shared. Most of the shared information is static. It doesn't change from message to message. If you insist on putting the static information into every message header, you needlessly increase the amount of processing per message. 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 ************************************************************************************* "Burdett, David" <david.burdett@commerceone.com> on 09/12/2001 01:09:25 AM To: Martin W Sachs/Watson/IBM@IBMUS, "Ian. C. Jones (E-mail)" <ian.c.jones@bt.com> cc: "'William J. Kammerer'" <wkammerer@novannet.com>, "ebXML Messaging (E-mail)" <ebxml-msg@lists.oasis-open.org> Subject: T2 The answer isn't always "you need a CPA" was RE: T2 PLEASE REA D - Suggested Change - add "From" Service and Ac tionto the header Marty (and also Ian Jones) You said ... >>>The solution of piling additional information into the message header to make up for the lack of a CPA should not be considered acceptable.<<< The ebXML messaging group has **agreed** that we want to separate the ebXML Messaging and CPPA specs so that they can be implemented independently or together (Ian, please correct me if I am wrong). I like others believe that CPAs can offer many benefits, particularly if you are doing individual point-to-point communications which **need** to be different in every case. Using a CPA for these situations will make it much easier to set up these types of links. However I think there is another use case where communities of users agree to exchange information in largely the same (or a few different) ways. This means that separate agreements for each link are not necessary and in fact create a barrier as it becomes a pre-requiste to negotiate re-negotiate the CPA before a new type of message can be sent that supports a new busines process. The alternative approach is to register your public key certificate, and the URLs associated with sending or receiving your messages with a particular service and action. For many businesses the same URL for all services and actions will be OK. What I am trying to do is make sure that ebXML works, as the group has agreed, either with a CPA or without. To this end I am making, what I hope are constructive suggestions on how to fix problems where they exist. So come on Marty !! make a suggestion on how to solve the problems we are trying to fix without saying ... "you need a CPA" !! Best wishes David -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Monday, September 10, 2001 7:55 PM To: Burdett, David Cc: 'William J. Kammerer'; ebXML Messaging (E-mail) Subject: RE: T2 PLEASE READ - Suggested Change - add "From" Service and Ac tionto the header Some problems are caused only by the "without a CPA" requirement. In this case, the problem is also related to "without a BPSS instance document".The simplest answer is to use a CPA and BPSS instance document. The next simplest answer is to recognize that the two parties have to have certain shared knowledge in order to communicate. If this knowledge is not documented in a CPA, the two parties have to find another way to share the necessary knowledge such as phone and fax. The solution of piling additional information into the message header to make up for the lack of a CPA should not be considered acceptable. 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 **************************************************************************** ********* "Burdett, David" <david.burdett@commerceone.com> on 09/10/2001 07:56:19 PM To: "'William J. Kammerer'" <wkammerer@novannet.com>, "ebXML Messaging (E-mail)" <ebxml-msg@lists.oasis-open.org> cc: Subject: RE: T2 PLEASE READ - Suggested Change - add "From" Service and Ac tionto the header William Using RefToMessageId only solves part of the problem. Specifically it does not solve the following ... 1. How does the recipient of a message know what to put in the Service and Action for the message they return in the absence of a CPA (this is from the Bank Payment example) 2. To use RefToMessageId, the sender of a message, where a reply is expected, would have no option but to save the data from the EVERY message even though the message was sent with deliverySemantics of BestEffort. This should not be necessary. How can it be avoided? 3. If you are using PartyId, Service and Action to route a message, how do you know which MSH at the Party should receive the message when Service and Action have fixed values (as in an error message)? With the current spec, a Party could only have one MSH ... even if it were IBM. As stated before we need solutions to ALL the problems unless you think the above are not problems. Regards David -----Original Message----- From: William J. Kammerer [mailto:wkammerer@novannet.com] Sent: Monday, September 10, 2001 4:23 PM To: ebXML Messaging (E-mail) Subject: Re: T2 PLEASE READ - Suggested Change - add "From" Service and Ac tionto the header I agree with Bob Miller wholeheartedly on the issue of (not) adding "From Service" and "From Action" elements to the Message Header. David Burdett already gave the solution - and it is most elegant: "[the sender] would have to store information from the original message that was sent and use the RefToMessageId to determine which application had made the original Transfer Request." So with reconciliation possible, why require more and more junk to be added to the spec, especially that which can easily be accommodated with programming? Therefore, I second Bob and "...recommend the issue be dismissed without further action." P.S., for those of us with short attention spans, could posters please chop off extraneous junk (like the entire responded-to e-mail) and avoid commenting "inline"? William J. Kammerer Novannet, LLC. ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC