RE: More issues to resolve

[Dick Brooks <dick@8760.com>]

Prasad,

I'll compile a list of requirements and send to you. 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: Prasad Yendluri [mailto:pyendluri@webmethods.com]
> Sent: Tuesday, December 05, 2000 4:08 PM
> To: Dick Brooks
> Cc: Christopher Ferris; Prasad Yendluri; ian.c.jones@bt.com;
> ebxml-transport@lists.ebxml.org
> Subject: Re: More issues to resolve
>
>
> List-Unsubscribe:
>  <mailto:ebxml-transport-request@lists.ebxml.org?body=unsubscribe>
> List-Archive: <http://lists.ebxml.org/archives/ebxml-transport>
> List-Help: <http://lists.ebxml.org/doc/email-manage.html>,
>  <mailto:ebxml-transport-request@lists.ebxml.org?body=help>
>
> No problem at all Dick. Could you please pass  me any references and the
> details of any specific requirements from the  Energy industry that you
> could share at this point.
>
> Thanks, Prasad
>
> Dick Brooks wrote:
>
> > 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
>
>
>