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