RE: A suggestion for async resolution.... :o)

+1. 
 
We should look at this more from the perspective of 
 
 
-- Do we need the granularity of WS-Addressing. (meaning proposed
async=full, never, async-only) switches at the binding level. 
(Proposals 2, 3)
-- Do we need to define the response binding and if so in which way?
(Proposals 2, 3)
-- Do we need to define the SOAP1.x/HTTP message level protocol (all
proposals deal with this, albeit in a similar way as Proposal 2
encompasses 1) 
-- Do we need programming level hints to indicate async support 
 
Everyone, please note that some of these decisions are independent. If
we do not need granularity at the binding, then Proposal 4 is
sufficient. 
 
If we need to specify response bindings and architect them, Proposal 4
can be combined/composed with approaches in Proposal 2 or Proposal 3. 
 
If we need programming level contracts/hints in WSDL to require
asynchronous programming model, we need to look at a different markup or
reusing the same markup (Proposal 1 Open Issues, Proposal 3, Anish's
email). 
 
So, instead of knocking down one proposal against the other, perhaps the
group can benefit from "chad" or any other decision making point to
really vote on granularity, response-binding and programming model
issues. Some bits and pieces from proposals can be easily combined if we
were to go that route. 
 
Thanks. 
 
--umit
 
 
Ps. As I write this, I am realizing it was a poor choice of use to
indicate the granularity by calling the flag "Async" at the binding
level. Even the very first Oracle/SAP/IBM proposal named it properly to
indicate what it really stood for, enabling multiple http connections. 
 
 


________________________________

	From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Katy Warr
	Sent: Monday, Nov 07, 2005 5:09 AM
	To: mark.nottingham@bea.com
	Cc: public-ws-addressing@w3.org
	Subject: A suggestion for async resolution.... :o)
	
	

	Mark, 
	
	Please may I make a suggestion which might help us reach swifter
resolution to the issues tomorrow? 
	
	We have 4 possible proposals on the table: 
	1. (Initial SAP/Oracle/IBM proposal) Superceded 
	2. Marc's proposal based on 1+ Anish's friendly amendment 
	3. David's proposal 
	4. Umit's/my proposal 
	
	Rather than discuss the above as complete proposals, could we
separate into composable functions and discuss as such?  I.e.: 
	
	A. Specification of async only or sync only at binding level
	    Should we opt for:
	            asyncOnly attribute from proposal 2 OR wsaw:Async
from proposal 3 OR no additional flag from proposal 4 (OR other) 
	
	B. Specification of binding for async response 
	     Should we opt for 
	           wsaw:Async binding semantics from proposal 2 OR
wsaw:ResponseBinding semantics from proposal 3 OR no response binding
specification (OR other) 
	
	C. Specification of async at the interface/op level 
	     Should we opt for 
	           Anish's friendly amendment to 2 OR no specification
(OR other) 
	
	There may be finer points that I have missed, but this structure
might help focus the debate.  
	
	Many thanks 
	Katy