RE: DRAFT TRP Work Plan

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

>>>Are we talking about transport bindings here? <<<

No I'm talking about existing specs that address or include "messaging"
specs that cover the same space as ebXML Messaging, rather than
communication protocols like HTTP, SMTP.

For example specs like IOTP addresses B2C commerce and already include specs
for reliable messaging and how to use digital signatures using XML. Version
2.0 of IOTP that is just beginning to get going is an ideal candidate in my
mind to use ebXML TRP, but it can only do it if we include in the ebXML spec
function. We therefore need to review IOTP (and other specs like) to see how
they could use ebXML MEssaging as an alternative. If we don't we run the
risk of our specs being dismissed because of missing functionality.

David 

-----Original Message-----
From: Gordon van Huizen [mailto:gvanhuiz@progress.com]
Sent: Friday, August 18, 2000 12:43 PM
To: David Burdett
Cc: 'Jim Hughes'; ebxml transport
Subject: Re: DRAFT TRP Work Plan


Are we talking about transport bindings here? I thought we had agreed in
San Jose that these should be in the spec, at least as an appendix. I
agree with David that the work needs to be done, whether it's documented
or not, to ensure that the rest of the spec provides suffieient support
for the real transports that will be used. I would think that including
documentation of the bindings, without necessarily being prescriptive,
would be useful for developers to see how artifacts in the spec map to
implementations over the various transports.

I'm optimistic that the spec can contain enough detail that
implementations can occur against the targeted protocols, but we need to
at least think through real world implementations to be sure. This is
particularly important for reliable messaging over anything but
MQSeries.

-gvh-

David Burdett wrote:
> 
> Jim
> 
> Enabling other protocols to bridge to ebXML is not part of the spec it's
an
> activity. In outline what we need to do is:
> 1. Agree other protocols to review
> 2. Analyze those protocols to identify gaps which would prevent their
> functionality being supported and identify/suggest changes to the spec
that
> need to be made
> 3. Make the changes to the spec.
> 
> What prompted me to add this activity is that IOTP will, I think, need
> synchronous communication and the current ebXML TRP spec doesn't support
> this.
> 
> Regards
> 
> David
> 
> -----Original Message-----
> From: Jim Hughes [mailto:jfh@fs.fujitsu.com]
> Sent: Thursday, August 17, 2000 2:19 PM
> To: ebxml transport
> Subject: Re: DRAFT TRP Work Plan
> 
> Rather than overload the Gantt chart with details (I think tracking at the
> major function level is enough), these ideas should be inserted into the
> draft document as placeholders (as Gordon suggests in his next message),
> and then someone assigned to come up with a draft by a certain date that
is
> targeted to be inserted into a projected version of the Messaging Spec.
> 
> I did put in a separate line item for the Service API because I think it
is
> a gaping hole.
> 
> Jim
> 
> At 10:31 AM 8/17/00 -0700, Gordon van Huizen wrote:
> >I would also add (and this overlaps I believe with 2 & 3): Transport
> >Bindings. The first thing to do would be enumerate the transports for
> >which bindings will be specificed (HTTP, FTP, SMTP, MQ?).
> >
> >-gvh-
> >
> >David Burdett wrote:
> > >
> > > Jim
> > >
> > > There are a number of work items that I think we need to add to the
> plan.
> > >
> > > 1. The creation of a service interface (API) specification for how
> > > applications can interact with an ebXML Messaging Service (we
discussed
> > this
> > > today on the call).
> > > 2. Support for other messaging protocols. One of our objectives is:
"4)
> to
> > > enable existing "messaging" solutions to "bridge" to the ebXML
> solution".
> > > 3. Development of how our protocols work synchronously. Specifically
how
> > > ebXML can work where an HTTP client is talking to an HTTP server. This
> > would
> > > be required, for example to support the way the Internet Trading
> Protocol
> > > Works.
> > >
> > > David
> > >