Re: Follow-up to Question on CR33

Doug,

When we had an off-line chat about this a while ago, I suggested that it 
was very likely, for any given operation, that anon and foo were likely 
to be mutually exclusive.

I personally don't believe the proposal that you and Anish put forward 
("[not] a real address") is objectionable, in the sense that Jonathan 
has suggested -- that it pollutes WS-A with RM-ness. However, I can see 
that it does make the contract specification more vague.

Going back to our earlier conversation: Why not define an RM WSDL marker 
to say: "a special address, the RM anon URI", and set WS-A 
anon=prohibited (or whatever the syntax is), or omit the WS-A marker 
altogether?

In the concrete case of RM, it would seem wrong to use WS-A anon, when 
the application wants to use RM anon. The two URIs are quite different, 
to my way of thinking -- the RM Anon URI is like a hybrid of WS-A anon 
and none, in that it permits the responder to decide whether to reply, 
and if it does choose to do so, it must be on the back-channel. I still 
think that WS-A anon does not permit a null response (a mere ack), on my 
reading of the WS-A SOAP Binding. Therefore, one could argue that trying 
to overload the same WSDL marker for very different behaviours is not 
good practice/not precise enough.

Overall, the question seems to be: should WS-A attempt to accommodate 
additional special URIs, or just deal, at its level, with its own 
limited repertoire? It almost feels like what you want is an extension 
facility built in to WS-A WSDL, so you can put an app-defined value in a 
WS-A marker (special="foo").

Alastair

Doug Davis wrote:
>
> After some off-line chats I realized that I may need to elaborate on 
> why I came to the conclusion that this solely a WSA issue and why 
> there's this implicit restriction that no other WS-* spec can define a 
> new special non-addressable URI.  Let's examine the following use-case:
>
> - a server only supports sync responses - so it can support "anon", 
> "none" and "foo" replyTo's.  'foo' is a new magic URI that some spec 
> defined
> - client A only knows about WSA
> - client B knows about WSA and WS-foo
> - the server, knowing it wants to tell people it can only support sync 
> responses adds the wsaw:Anonymous="required" wsdl marker
>
> Client A sees that marker and sets replyTo to 'anon' - all is ok
> Client B knows that the server supports WS-foo, but the wsaw:Anonymous 
> marker says only "anon" and "none" are supported
> Support for Client B + WS-foo appears to be restricted.
>
> Even if the server adds another wsdl marker that say "replyTo can be 
> foo" - what is client B supposed to do when it sees conflicting wsdl 
> markers?
> The server can not set wsaw:Anonymous to 'optional' because that mean 
> that clients can pass in "www.ibm.com"  - which isn't what the server 
> wants.
> What can the server put in its WSDL to get the desired results?
>
> Its because I don't know the answer to these questions that I come to 
> the conclusion that the use of wsaw:Anonymous="required" implicitly 
> means that no other WS-* spec can do what WSA has done and define a 
> new non-addressable URI for use in the replyTo and faultTo headers. 
>  And, I think this makes it a WSA issue and not an RM issue - RM is 
> just the first unlucky WS-* spec to expose this problem.  :-)
>
> thanks,
> -Doug
>
>
>
> *Doug Davis/Raleigh/IBM@IBMUS*
> Sent by: public-ws-addressing-request@w3.org
>
> 09/13/2006 09:52 AM
>
> 	
> To
> 	public-ws-addressing@w3.org
> cc
> 	
> Subject
> 	Question on CR33
>
>
>
> 	
>
>
>
>
>
>
> After Monday's conf call I was thinking about the "status quo" option 
> and I was wondering about the implications of that.  As currently 
> worded, the wsaw:Anonymous=required option would prevent someone from 
> using any URI in wsa:ReplyTo except "anonymous".  This is a bit too 
> restricted because WSA itself, during its work on the spec, found the 
> need to define another non-addressable URI: "none".  I believe there 
> was some other CR which was adopted to loosen the wording a bit to 
> allow for this special case.  So, the question that I keep trying to 
> come to terms with is whether or not the WG is aware of the implicit 
> restriction of the "status quo" option.  What it basically means is 
> that no other WS-* spec can ever define its own non-addressable URI to 
> be used in wsa:ReplyTo when this WSDL marker is used.  Ever.  Ignore 
> RM, or another variant of a URI that means 'the backchannel'.  What if 
> some other spec wanted to do exact what WSA did and define a new URI 
> to mean something special - e.g. like 'none' means 'trash it'?  They 
> can't do it.  Because the semantics of this wsdl marker are tied to 
> specific URI values (and, as of now, this list isn't extensible) and 
> not to whether or not the server is willing/able to send async 
> responses, WSA has in essence banned other specs from doing exactly 
> what it itself has found a need to do: extend the list of 'special 
> URIs'.  While this is obviously an option, is it really the intent of 
> the WG to not allow this flexibility for future specs?
>
> thanks
> -Doug