RE: TRP Work Plan - Version 17 Aug 00

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

We also need to do more than just RosettaNet. My initial candidate list (and
suggested responsibilities) would be:

* AS1/AS2 - Dick Brooks?
* IOTP - David Burdett
* RosettaNet - Prasad Yendluri?
* MQ Series - John Ibbotson?

Any more standards we should consider?

David


-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
Sent: Friday, August 25, 2000 7:07 AM
To: David Burdett
Cc: 'Jim Hughes'; ebxml transport
Subject: Re: TRP Work Plan - Version 17 Aug 00


I agree. We should see if we can't get the RNIF mapping
out of the POC team. Prasad and others basically performed
this function for purposes of the SJ demo. It would be 
a useful, (non?-)normative appendix IMHO.

Chris

David Burdett wrote:
> 
> Jim
> 
> ... in an earlier email I suggested we added a comparison with existing
> protocols (RosettaNet, IOTP, AS1/AS2) ... as a separate work activity. I'm
> not sure we resolved this. I think we need to add it as a separate
activity
> since:
> 1. We need to do this work to meet our requirements
> 2. It is a significant piece of work, so I don't want us to forget it
> 
> David
> 
> -----Original Message-----
> From: Jim Hughes [mailto:jfh@fs.fujitsu.com]
> Sent: Monday, August 21, 2000 10:11 AM
> To: ebxml transport
> Subject: RE: TRP Work Plan - Version 17 Aug 00
> 
> My reasons for adding it to the Work Plan as I did was:
> 
> - simplicity
> - there may be vendors which will create Messaging Services, and these
> Services need to be interoperable with respect to higher layer business
> processes
> 
> But I don't care about the packaging decision, as long as someone gets
> going on getting this interface decided for the POC and we look towards a
> final solution. Rik/Chris, how do you want to lead this resolution?
> 
> Jim
> 
> At 12:58 PM 8/18/00 -0700, David Burdett wrote:
> >Jim
> >
> >I firmly beleive we *don't* put the Service API spec into the messaging
> spec
> >but should instead keep it as a separate document. The reasons are:
> >1. The API's you use to interface with the ebXML Messaging Service is
> purely
> >an implementation decision. If, for example you wanted to put the service
> on
> >a PDA then compliance with the Service Interface could be too burdensome
> >2. More importantly conformance to the API is not required for
> >interoperability between trading partners. All that is needed is
compliance
> >with the wire protocol
> >3. It will make it harder to maintain and revise the document as the
editor
> >role will become a bottleneck
> >4. There is a requirement in the Overview & Requirements document that
says
> >...
> >
> >         "1) Servers/systems that support the exchange of documents shall
> be
> >treated as "black boxes"  "
> >
> >We definitely do need the spec as it will make it easier for business
> >process (i.e. application) implementers to do plug-and-play with ebXML
> >services from different vendors.
> >
> >David
> >
> >
> >-----Original Message-----
> >From: Jim Hughes [mailto:jfh@fs.fujitsu.com]
> >Sent: Thursday, August 17, 2000 2:27 PM
> >To: ebxml transport
> >Subject: TRP Work Plan - Version 17 Aug 00
> >
> >
> >Based on comments from the TRP meeting this morning and several email
> >messages, here is a new cut of the plan.
> >
> >Significant changes:
> >
> >- added Service API to the plan. I believe the first version must be
folded
> >into the overall Messaging Services Spec within the month, and some
amount
> >of the Service API should be approved in Tokyo.
> >
> >- I have indicated where we should release the Messaging Spec, the
Service
> >API drafts and the Messaging Spec to the POC.
> >
> >Other notes:
> >
> >- as before, I've made some assumptions about the Security work, so I
need
> >confirmation of these dates...
> >
> >- I arbitrarily assigned major version numbers to the Messaging Services
> >Spec (based on approval at plenary meetings) and showed how the
subordinate
> >specs are being folded into it.
> >
> >- I reduced the chart scope to just the Vancouver meeting so it prints
> >better. We don't know what we're doing between Vancouver and Vienna just
> >yet...!
> >
> >- 5 days is shown for Quality Team review, with two-week Member reviews
> >immediately following. We may need some time inserted to react to Quality
> >Team comments...
> >
> >And apologies to Rik/Chris, as they haven't yet approved/commented on the
> >work plan. I trust they will concur in our planning work during their
> >absence!
> >
> >Jim

-- 
    _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903