RE: DRAFT TRP Work Plan

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

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
> >