RE: More issues to resolve

[Rik Drummond <rvd2@worldnet.att.net>]

how are we coming on this?.. is it working? rik

-----Original Message-----
From: ian.c.jones@bt.com [mailto:ian.c.jones@bt.com]
Sent: Tuesday, December 05, 2000 12:00 PM
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