W3C home > Mailing lists > Public > public-ws-addressing@w3.org > September 2006

RE: Proposal for CR33

From: Doug Davis <dug@us.ibm.com>
Date: Mon, 11 Sep 2006 15:14:11 -0400
To: Jonathan Marsh <jmarsh@microsoft.com>
Cc: public-ws-addressing@w3.org
Message-ID: <OF68F3D3D7.985449CA-ON852571E6.00671EA2-852571E6.0069AA5F@us.ibm.com>
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 
Received on Monday, 11 September 2006 19:14:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:14 GMT