RE: More issues to resolve

[Dick Brooks <dick@8760.com>]

Prasad,

The U.S. Energy industry currently uses synchronous receipt
acknowledgements. I would like to work
with you to ensure that the Energy industry requirements are included in the
design.

Thanks,

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
> Sent: Tuesday, December 05, 2000 1:06 PM
> To: Prasad Yendluri
> Cc: ian.c.jones@bt.com; ebxml-transport@lists.ebxml.org
> Subject: Re: More issues to resolve
>
>
> Thanks Prasad!
>
> Chris
>
> Prasad Yendluri wrote:
> >
> > Chris/Ian (et al),
> >
> > Regarding 13, there seems to be a consensus that we need this
> functionality.
> > I agree that we definitely want to see support for synch
> responses, acks,
> > errors in ebXML. Towards that end, I volunteer to put together
> a proposal
> > for it.
> >
> > Thanks, Prasad
> >
> > -----Original Message-----
> > From: Chris.Ferris@east.sun.com [mailto:Chris.Ferris@east.sun.com]
> > Sent: Tuesday, December 05, 2000 10:26 AM
> > To: ebxml-transport@lists.ebxml.org
> > Subject: Re: More issues to resolve
> >
> > Thanks Ian!
> >
> > Everyone, I urge you to read Ian's message.
> > If you have comments on any of the issues,
> > please let's start the discussion NOW via email.
> >
> > For items which have no formal proposal, let's
> > get some people signed up to submit one (or more).
> > Volunteers are always welcomed;-)
> >
> > Cheers,
> >
> > Chris
> >
> > -----Original Message-----
> > From: ian.c.jones@bt.com [mailto:ian.c.jones@bt.com]
> > Sent: Tuesday, December 05, 2000 10:00 AM
> > To: ebxml-transport@lists.ebxml.org
> > Subject: More issues to resolve
> >
> > All TR&P people
> >
> >         here are the next batch of issues for us to discuss.  I
> am starting
> > at 10 as we already have 7 points under discussion most ready
> for votes this
> > week.  I started with 4!! This is why we need to deal with
> these in groups
> > and not raise to many new ones in line with these discussions.
> If you want
> > to raise new things can you flag them and send me a copy to add
> to the list
> > so we deal with them in order.  We have still not cleared all the
> > outstanding issues form v0.21 and people are already raising
> issues against
> > V0.8!!
> >
> >         I hope 3 of these are a little less contentious to get
> a few quick
> > results.  I have also put in 1 big one from the Tokyo meeting
> that we still
> > did not resolve in a documented way.
> >
> >         Once we have resolved the first batch I will repost the
> issue with
> > the solution so that we have a visible record on the mail archive.
> >
> > ####
> > Issue 10
> > Title - Multiple PartyID
> > Detail -
> > 7.9.1   - Recommend changing phrase PartyID element to 'one or
> more PartyID
> > elements'.
> >
> > Proposal -      See above
> > Resolution -
> > Response By - Vote December 14 2000
> >
> > ####
> > Issue 11
> > Title - Version of Header
> > Detail -
> > 7.7.1.2 - Purpose to provide future capabilities: should be version of
> > header document being referenced. Should describe content below
> that level.
> >
> > Proposal - Clarify definition and usage - Someone to suggest wording!
> > Resolution -
> > Response By - Vote December 14 2000
> >
> > ####
> > Issue 12
> > Title - Service interface name
> > Detail -
> > 7.9.2.3 - Element misname: reference an element as
> BusinessServiceInterface:
> > should be as ServiceInterface as it defined in section 3.3.2
> line 430 and in
> > the XML DTD at line 566.
> >
> > Proposal - Define exactly what is meant by and the exact term
> to be used -
> > previous discussions favoured the ServiceInterface but it was never
> > accurately define to remove ambiguity.
> > Resolution -
> > Response By - Vote December 14 2000
> >
> > #################################################
> > ######## A BIG ONE #############################
> > Issue 13
> > Title - Synchronous messaging
> > Detail -
> >         DO WE SUPPORT synchronous transports for the
> response/error message
> > ?
> >         How are we going to document it
> > the following is a formal issue raised by Doug Bunting
> > 7.13.4  The wording of this section explicitly prevents  leaving out the
> > ErrorURI and relying on the immediate response available in some
> > transports.  For example, sending a message via HTTP may not require the
> > ErrorURI because the receiver always completes MS handling in
> "real time"
> > and  returns an Error document (if necessary) in the immediate HTTP
> > response.   Recommend this case be supported by including words to this
> > effect rather than  leaving it "outside the scope of this document".
> >
> > Proposal - The consensus seamed to be we need to do this! But,
> we need some
> > one to put a formal proposal for us to discuss, NOT just another yes we
> > should do this.
> > <Editor comment>If we are going to do this we need to have a
> proposal ready
> > for inclusion in the document for the January F2F </Editor Comment>
> > Resolution -
> > Response By - Vote December 14 2000 (If we are going to do this
> not actually
> > do it> with the volunteer to write the proposal.
> > ###################################
> >
> > Ian Jones
> > E-Commerce Engineer
>