RE: Proposal for CR33

If WS-RM wants something like the previous incarnation of Reference
Properties, then WS-RM should have asked WS-A to do that.  In fact,
WS-RM can still make such a request.  WS-A deliberately removed
Reference Properties for their reasons.  I will state that for the
record I was not in favour of removing Ref Properties and had prepared
material to make the argument that Reference Properties are
architecturally acceptable. [1] 
 
This is the problem of rolling out a base spec before a "customer" or
dependent spec is done.  
 
Cheers,
Dave
 
[1]
http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/0037.ht
ml


________________________________

	From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Doug Davis
	Sent: Monday, September 11, 2006 1:13 PM
	To: Jonathan Marsh
	Cc: public-ws-addressing@w3.org;
public-ws-addressing-request@w3.org
	Subject: RE: Proposal for CR33
	
	

	Still not clear to me how that can work. Its the server that
needs to do this identification not the client - and I thought the TAG
would frown upon using ref-p's to identify endpoints. 
	-Doug
	
	
	
	
Jonathan Marsh <jmarsh@microsoft.com> 
Sent by: public-ws-addressing-request@w3.org 

09/11/2006 04:05 PM 

To
Doug Davis/Raleigh/IBM@IBMUS 
cc
<public-ws-addressing@w3.org> 
Subject
RE: Proposal for CR33

	




	I think we agree on the crux of the issue "the RManonURI doesn't
identify a sequence, it just identifies the anonymous endpoint".  The
use of an infinite number of possible identifiers which are synonyms of
the WS-A "anonymous" uri is generally discouraged - I'll try to look up
the WebArch advice on this topic.  But the interaction of your RManonURI
with wsaw:Anonymous is symptomatic. 
	  
	I propose that you use our anonymous URI to identify the
anonymous endpoint, and use reference parameters to communicate the
sequence ID or whatever information is necessary internally to the
endpoint (identified as anonymous) to disambiguate states or other
internals. 
	  

________________________________


	From: Doug Davis [mailto:dug@us.ibm.com] 
	Sent: Monday, September 11, 2006 12:14 PM
	To: Jonathan Marsh
	Cc: public-ws-addressing@w3.org
	Subject: RE: Proposal for CR33 
	  
	
	It might be a terminology issue but the RManonURI doesn't
identify a sequence, it just identifies the anonymous endpoint. 
	
	If the WG does close it with no action then what would be the
suggested solution for: 
	1 - a new spec to define their own anon-like URI (as the core
spec says it may) and have a WSDL marker saying it only supports
non-addressable URIs?  The current WSA WSDL marker doesn't allow for
this. 
	2 - in a scenario where two anonymous clients are talking to a
server what would be the interoperable way the server can uniquely
identify each one for the purposes of sending back messages on a
subsequent connection (with and w/o the use of RM sequences)?  If RM
used the WSA anon URI its not clear to me how the server could ever
know, upon receipt of a 2nd connection from a client, how it would know
which client made the connection.  This may not be a WSA WSDL issue but
since you're suggesting that RM may be made a mistake by defining its
own anon-like URI, I'd be interesting in hearing alternatives. 
	
	I guess I'm still not clear why the text around this WSDL marker
can't simply be reworded to state that its to indicate whether or not
the server supports async responses.  I know some people are worried
about the definition of 'async' but is that really something we couldn't
work through?  To me, the use of the exact string representing the WSA
anon URI is not the important aspect of this marker, its the async-ness.
And this would be true even if RM didn't define its own anon URI. 
	
	thanks 
	-Doug 
	
	

	
Jonathan Marsh <jmarsh@microsoft.com> 
Sent by: public-ws-addressing-request@w3.org 

09/11/2006 02:37 PM 



To
Doug Davis/Raleigh/IBM@IBMUS, <public-ws-addressing@w3.org> 
cc
  
Subject
RE: Proposal for CR33

  



  	 



	
	
	
	I still summarize the core of the problem as the RM WG defining
anonymous-like functionality yet insisting that WS-Addressing provide
descriptive capabilities of RM-specific capabilities.  I continue to
find it beyond distasteful to put RM-specific description hooks in our
non-RM-dependent description capability. 
	 
	The argument that WS-A allows anonymous-type behavior outside
the WS-A anonymous URI is not compelling in the least.  In hindsight, we
shouldn't have been so accommodating to give you a loaded gun.  But now
that we have, I don't feel compelled to help you pull the trigger.
Instead, I hope to advise you on WS-A compatible ways to accomplish your
scenarios. 
	 
	As I understand it, the RM pseudo-anonymous URI serves two
purposes - it identifies the anonymous URI as the destination for the
(usually response) message, and it carries a sequence identifier to
facilitate future communication with the endpoint.  These are two
separate tasks, and the former seems completely duplicative of the WS-A
anonymous URI.  Complications arise when the same functionality is given
two or more syntaxes.  If at all possible, you should use one syntax.  I
think the WS-A anonymous URI should be used as the endpoint address in
these scenarios. 
	 
	The additional functionality of communicating a sequence
identifier maps nicely to the reference parameter functionality provided
by WS-A.  To date I have not heard, nor can I imagine, a compelling
reason not to use reference parameters.  The arguments floated so far
have been weak: 
	 
	1)       Identifiers need to be put in the URI.  Just because
the sequence identifier is an "identifier" and WS-A recommends against
putting endpoint identification information in a reference parameter is
no reason - because the sequence identifier does not identify the
endpoint - it identifies the sequence. Mashing this information
inappropriately into the address URI disguises the actual address -
which is why these pseudo-anonymous URIs are invisible to
wsaw:Anonymous. 
	2)       Reference parameters are always opaque.  The opacity of
reference parameters is no different than the opacity of query
parameters.  One should be able to use them opaquely in generic
contexts, but that doesn't prevent one from documenting the internal
structure and allowing a smarter client from manipulating that
structure.  Many web sites such as local.live.com document their query
parameters for those who want additional functionality beyond generic
link-clicking.  Actually, WS-RM engages in just such documentation in
providing a URI template.  Surely you can't object to an EPR template
instead? 
	 
	As a consequence, I think the WS-A WG should close this issue
with no action against the WSDL binding spec, and file a comment against
WS-RM about the lack of composition of the pseudo-anonymous URI with
wsaw:Anonymous.  We should request that WS-RM use the perfectly adequate
facilities provided by WS-A and not invent new ones. 
	  

	  
	
________________________________


	
	From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Doug Davis
	Sent: Wednesday, August 30, 2006 11:27 AM
	To: public-ws-addressing@w3.org
	Subject: RE: Proposal for CR33 
	 
	
	What you're basically advocating is the removal of the
wsaw:Anonymous element when RM's URI template is used - while to someone
who would only use "optional" in there anyway wouldn't really care, I
suspect people who want to use "required" might have a problem with
that.  A WSA-only client may want to see wsaw:Anonymous=required to know
that it must use WSA's anon.  While a RM+WSA client seeing that same
WSDL element would correctly interpret it to mean that RM's anon is
prohibited.  Given that WSA core spec allows for other specs to define
anonymous-like URIs, it makes sense to me that this WSDL element should
allow for those situations. 
	
	To me this element should talk about the asynchronous support of
the server.  However, if the WG really wants to keep it focused on the
specific URI itself then maybe another option would be to add another
value for this wsdl element.  Something that means "anon-like required"
- so its similar to "required" but allows for other possible values as
long as they are non-addressable.  This gives people to ability to
really be picky and just allow WSA's anon, but also support others.
(just brainstorming here) 
	
	thanks 
	-Doug 

	
"Jonathan Marsh" <jmarsh@microsoft.com> 

08/30/2006 02:12 PM 

  



To
Doug Davis/Raleigh/IBM@IBMUS, <public-ws-addressing@w3.org> 
cc
  
Subject
RE: Proposal for CR33


  



  	 


	
	
	
	
	Sorry I missed last week's call, but I still haven't seen enough
evidence, including in last week's minutes, proving that RM's anonymous
template design is the least of all evils to be wholeheartedly in favor
of such a proposal.  An EPR with an anonymous URI (identifying the
address of the service using a standard mechanism that works well with
wsaw:Anonymous) plus a reference parameter (conveying other information
to the endpoint which it can use to help establish subsequent
connections) seems to accomplish all the desired goals. 
	
	I also recognize stability of the WS-RM and WS-A WSDL binding
specs is important, but something has to give here, perhaps the simplest
path forward is to add the simple advice to WS-RM not to combine RM with
wsaw:Anonymous="required" because of the unintended side effect of
prohibiting RM's pseudo-anonymous address.  The resulting loss of
descriptive capability doesn't seem catastrophic. 
	  

	
	  
	
________________________________


	
	
	From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Doug Davis
	Sent: Wednesday, August 30, 2006 9:54 AM
	To: public-ws-addressing@w3.org
	Subject: RE: Proposal for CR33 
	
	
	Yup - the entire naming issue is a problem.  Obviously the
current name "Anonymous" doesn't 
	convey what this CR is trying get to.  And as you and other have
pointed out perhaps "Connection" 
	isn't right either.  I think it might be useful to first figure
out what this WSDL element is trying to 
	define and then pick a name. 
	
	So, let's start with this.... 
	
	If the wsaw:ZZZ element were defined with the proper terminology
to say that this element 
	is trying to convey whether or not the endpoint supports the
notion of sending responses 
	(either normal or faults) asynchronously - would that be
something people could 
	support? 
	
	(I'm not asking for people to agree to the term 'asynchronously'
but rather to just the 
	idea that everyone knows what it is supposed to mean.  If we can
get agreement to 
	on the idea then we can move on to finding the right wording.) 
	
	thanks 
	-Doug 

	
"Jonathan Marsh" <jmarsh@microsoft.com> 

08/30/2006 12:32 PM 

  



To
"Anish Karmarkar" <Anish.Karmarkar@oracle.com>,
<public-ws-addressing@w3.org> 
cc
Doug Davis/Raleigh/IBM@IBMUS 
Subject
RE: Proposal for CR33



  

  



  	 


	
	
	
	
	Still digesting this, but one comment is simply on the
terminology and
	names.  The concept (e.g. the property name) is termed
"addressable
	response endpoint" yet the syntax is named wsa:NewConnection.
Perhaps a
	unified name like wsaw:Addressable would be more appropriate.
Although
	"addressable" as a term does seem to include the anonymous URI
so maybe
	that doesn't work either...
	
	I'm also concerned the preoccupation with "new connection" is
	SOAP-Binding specific.  The WS-A Core doesn't mention
connections at all
	when defining the anonymous URI.
	
	> -----Original Message-----
	> From: public-ws-addressing-request@w3.org
	[mailto:public-ws-addressing-
	> request@w3.org] On Behalf Of Anish Karmarkar
	> Sent: Wednesday, August 16, 2006 12:10 AM
	> To: public-ws-addressing@w3.org
	> Cc: Doug Davis
	> Subject: Proposal for CR33
	> 
	> Dug and I took an action during this week's call to send out a
	proposal
	> for CR33 [1]. Word version of the proposal is attached. It is
a marked
	> up version of section 3.2 [2] of the WS-Addressing 1.0 -- WSDL
Binding
	> spec. PDF (diffed and non-diffed  versions) are also attached.
	> 
	> -Anish
	> --
	> 
	> [1]
http://www.w3.org/2002/ws/addr/cr-issues/Overview.html#cr33
	> [2]
http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/#anonelement