Re: More issues to resolve

[Christopher Ferris <chris.ferris@east.sun.com>]

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
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;One Network Drive;Burlington;Ma;01803-0903;USA
version:2.1
email;internet:chris.ferris@east.sun.com
title:Senior Staff Engineer
fn:Christopher Ferris
end:vcard