RE: TRP Work Plan - Version 17 Aug 00

[David Burdett <david.burdett@commerceone.com>]

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-