Re-sending because of addressing error.
*************************************************************************************
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
*************************************************************************************
---------------------- Forwarded by Martin W Sachs/Watson/IBM on 09/06/2001
03:17 AM ---------------------------
Martin W Sachs
09/06/2001 02:49 AM
To: David RR Webber - XMLGlobal <Gnosis_@compuserve.com>
cc: Arvola Chan <arvola@tibco.com>, ebtwg@lists.ebtwg.org,
ebxml-cppa@oasis-open.org, ebxml-msg@oasis-open.org, Duane Nickull
<duane@xmlglobal.com>, christopher ferris <chris.ferris@east.sun.com>
From: Martin W Sachs/Watson/IBM@IBMUS
Subject: Re: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment
(Document link: Martin W. Sachs)
David,
Regarding "Either the CPA or the CPP should contain this.": I don't know
what "this" is.
Let me try again. A CPP can contain multiple sets of capabilities if its
owner chooses to describe all of its capabilities and all of the
collaboration protocols it supports. Formation of the CPA consists of
putting the two trading partners' CPPs together and picking out the common
elements that go with the one collaboration protocol that they want to
perform. If each party simply mechanically installed the other's CPP,
there is no guarantee that the two systems would know how to behave toward
each other. Of course a human being could read the other party's CPP and
figure out what information it has to install. That gets back to my
original point. If two parties choose to install copies of an incomplete
CPA, the need to talk together and figure out what missing information to
fill in before they can do business. For simple cases, one of the parties
can prepare a CPA template and send it to the other party along with the
BPSS instance document. They can then exchange whatever information is
missing (e.g. endpoint addresses) and fill that in manually. If more than
one or two items need to be filled in, they might as well use tools to
automatically generate a complete CPA from their CPPs and then install
copies of it.
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
*************************************************************************************
David RR Webber - XMLGlobal <Gnosis_@compuserve.com>@compuserve.com> on
09/05/2001 10:27:58 AM
To: Martin W Sachs/Watson/IBM@IBMUS
cc: Arvola Chan <arvola@tibco.com>, ebtwg@lists.ebtwg.org,
ebxml-cppa@oasis-open.org, ebxml-msg@oasis-open.org, Duane Nickull
<duane@xmlglobal.com>, christopher ferris <chris.ferris@east.sun.com>
Subject: Re: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment
Message text written by Martin W Sachs
>MWS: I could accept this point but I would not want to see the
practice used as a catch-all for eliminating information from the CPA that
should be there.
<<<<<<<<<<<<<<<<<<<
Martin,
And here-in lies the rub. I think we need flexiblity here.
Either the CPA or the CPP should contain this.
This covers the two use cases where there is either a
formal agreement in place, or someone is offering
an open service to people who have access to their
CPP - and all points and combinations in-between.
Private and public use models. If you put stuff in the
TRP header instead - then you are obviously doing a very
public interaction - unless it is travelling over a VPN.
Anyway - as I said before - all we can do is provide
sensible guidelines here on best practice. You cannot
totally prevent individual implementers from morphing
things - but then they do so at their own risk.
DW.
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebtwg.org/ob/adm.pl>