RE: TRP Work Plan - Version 17 Aug 00

[mwsachs@us.ibm.com]

*************************************************************************************

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 08/30/2000
10:52 AM ---------------------------

Martin W Sachs
08/30/2000 10:50 AM

To:   David Burdett <david.burdett@commerceone.com>
cc:
From: Martin W Sachs/Watson/IBM@IBMUS
Subject:  RE: TRP Work Plan - Version 17 Aug 00  (Document link: Martin W.
      Sachs)

See rejoinders in line.

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 Burdett <david.burdett@commerceone.com> on 08/28/2000 05:02:33 PM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   "'gvh@progress.com'" <gvh@progress.com>, "'Jim Hughes'"
      <jfh@fs.fujitsu.com>, ebxml transport
      <ebxml-transport@lists.ebxml.org>
Subject:  RE: TRP Work Plan - Version 17 Aug 00



See comments inline.

David

-----Original Message-----
From: mwsachs@us.ibm.com [mailto:mwsachs@us.ibm.com]
Sent: Friday, August 25, 2000 10:51 AM
To: David Burdett
Cc: 'gvh@progress.com'; 'Jim Hughes'; ebxml transport
Subject: RE: TRP Work Plan - Version 17 Aug 00


Dave,

I don't think that we disagree at all.  For simple case, a URL obtained by
phone is sufficient agreement.
>>>I agree. However do you also accept the case where one party downloads a
party profile from another and then, **with no prior contact** use that
information to send a message. IE there is no priore *agreement* as
such.<<<

MWS:  Sure.  I would expect that the profile would indicate that the party
accepts a message without a prior TPA.

For complex B2B situations, an electronic
TPA that can be copied and automatically installed by both partners can
provide great value by assuring compatible configurations.
>>>Yes I agree, except it can only be an "agreement" if there is an offer
and acceptance, and in this model there isn't.<<<

MWS:  Again, I agree.  Offer and acceptance is an additional Business
Process
which can be defined by a BP model.  Or the offer and acceptance can be
accomplished by representatives of the two parties sitting together at a
TPA authoring tool and writing the TPA together. I believe that the first
job of the TP team is to define the contents of the profile and TPA.  At
the same time, we could consider adding tags needed to identify negotiable
items, though this might best be handled in a side document that goes with
the profile.  The first step should be to come up with a profile and TPA
that
can be negotiated by people and later add the automated offer/negotiation
functions.

In my mind, the issues around the application-messaging service concptual
interface are not how to find the trading partners but how to assure
ourseives that the MS specification includes everything that is needed for
communication between the application and the MS and that this is clear to
implementers.
>>>Absolutely right !!<<<
MWS:  I accept  your accpetance :-)

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 Burdett <david.burdett@commerceone.com> on 08/24/2000 02:18:33 PM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   "'gvh@progress.com'" <gvh@progress.com>, "'Jim Hughes'"
      <jfh@fs.fujitsu.com>, ebxml transport
      <ebxml-transport@lists.ebxml.org>
Subject:  RE: TRP Work Plan - Version 17 Aug 00



Marty

I find myself agreeing and disagreeing.

Firstly, I agree that trading partner or party information is required to
be
known by each of the parties before they can work. I disgaree though that a
Trading Partner *Agreement* is the *only* way this can be done (see the use
cases I sent out yesterday).

I also agree that the *current* messaging services spec is insufficient
since it neither contains nor points to where you can find the relevent
party information. This however can be fixed.

David

-----Original Message-----
From: mwsachs@us.ibm.com [mailto:mwsachs@us.ibm.com]
Sent: Wednesday, August 23, 2000 6:41 PM
To: David Burdett
Cc: 'gvh@progress.com'; 'Jim Hughes'; ebxml transport
Subject: RE: TRP Work Plan - Version 17 Aug 00


Dave,

Please excuse me if I have already said this.

I am skeptical (agnostic?) that the Message Services Specification will
contain enough detail to assure interoperability.  Defining a TPA
specification will help.  RosettaNet provides the RosettaNet Implementation
Framework specification to supplement the PIP specifications. To me, the
RNIF looks an awful lot like a run-time interoperability specification.  I
felt the need to include 90 pages of text in the tpaML specification to
supplement the definition of the tags.  I believe that the analog of this
text belongs in our messaging service specification and other
ebXMLspecifications in order to guide the implementers of the run-time and
enhance the possibility of interoperable implementations.

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 Burdett <david.burdett@commerceone.com> on 08/22/2000 03:50:41 PM

To:   "'gvh@progress.com'" <gvh@progress.com>
cc:   Martin W Sachs/Watson/IBM@IBMUS, "'Jim Hughes'" <jfh@fs.fujitsu.com>,
      ebxml transport <ebxml-transport@lists.ebxml.org>
Subject:  RE: TRP Work Plan - Version 17 Aug 00



Gordon

I agree that awareness of the Interface is a benefit. I disagree that
"implementations of the wire protocol will require semantic knowledge that
is not imparted stricly from the fields in the header".

If we can't fully define, in our spec, the meaning or semantics behind ...
1. each field in the header
2. the meanings implied when these fields occur in combination within a
header
3. the meanings implied when messages (e.g. a normal message and it's ack)
are received in a specific sequence

... then, IMO, we are not doing our job properly.

If we REQUIRE that particular type of interface is used to make an ebXML
Messaging Service Spec work, then we are creating an additional barrier to
its use.

David

-----Original Message-----
From: Gordon van Huizen [mailto:gvanhuiz@progress.com]
Sent: Tuesday, August 22, 2000 4:07 AM
To: David Burdett
Cc: 'mwsachs@us.ibm.com'; 'Jim Hughes'; ebxml transport
Subject: Re: TRP Work Plan - Version 17 Aug 00




David Burdett wrote:
> I think it should be possible for two parties communicating using the TRP
> spec to achieve COMPLETE interoperability without implementing ANY of the
> Interface spec - i.e. conformance to the wire protocol alone should
suffice.
> Do you agree?

My assertion would be that successfully achieving interoperable
implementations of the wire protocol will require semantic knowledge
that is not imparted stricly from the fields in the header themselves
and can benefit from awareness of the Interface. But that's just a
hunch, since we aren't "there" yet. Regardless, the two levels must be
kept in synch for a developer to stand a chance of implementation, as
well as for us to actually get the spec work done. Witness the deltas
that are appearing elsewhere.

-gvh-