OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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