Re: Follow-up to Question on CR33

Having been in one of those off-line chats, I now agree that this is an
issue because of just the use-case that Doug gives.  I also agree it's
nothing to do with WS-RX.

I wouldn't say that the culprit is "required" per se.  If an endpoint
only supports anonymous, probably because it's an old-style
synchronous-only server, then it won't support WS:foo.  For this reason
I tend to think that we got CR22 wrong in that "none" should be
prohibited like everything else for "required", but that's a separate
question (an old-style server won't know how to handle none).

Of the three, "required" states clearly that the endpoint accepts
anonymous (and none) and nothing else.  The other two, strictly
speaking, only say that anonymous is or is not in the set of accepted
addresses, but say nothing about what other addresses might be
accepted.  The inference that in this case "clients can pass in
www.ibm.com" is not right.  With optional, clients don't know whether
they can pass in www.ibm.com or not, while with "required" they know
they can't.  Loosening "required" to "optional" in order to accommodate
WS-Foo loses information.

As I recall, one of the original recommendations of the Async Task Force
was that there be some way to indicate what set of addresses an endpoint
would accept for response endpoints, at least as far as a binding (e.g.,
I can send responses by HTTP or email).  We don't handle this directly,
but it will need to be done at some point (probably as a policy
assertion?).  We should at least make sure we've left room for that.

One way forward would be to clarify that "optional" and "prohibited"
make no statement about what other addresses might or might not be
allowed for response endpoints.  This in turn strongly implies that a
client should /not/ assume a given non-anon address would work. 
Everything not specifically permitted is unspecified, and so effectively
prohibited in the absence of other markers.

The WSDL in the use case would then have anonymous "optional" and an
additional "foo" element.  Client A would see optional, and nothing
else, and know that it  couldn't use www.ibm.com (strictly speaking,
that it can't assume that it can use it).  From client A's point of
view, "optional" with nothing else is essentially the same as
"required".  From client B's point of view there's a difference:
"optional" allows for "foo" while "required" doesn't.

I would argue that this much, at least, is fine for CR as it's just
clarifying the existing semantics (which were not what one might
naturally infer).  We might even go so far as to explicitly prohibit
addresses not specifically allowed.  Whether that's a semantic change is
open to interpretation.

Now, what about another server that supports both anonymous and, say,
email?  In lieu of a more complete description, we could invent a new
element for "anything not specifically defined elsewhere".  This would
leave us no worse off than we are now, as it's basically what's been
inferred anyway.  With "optional" and "anything else", client A knows it
can use www.ibm.com.  Client B should interpret "optional" and
"anything" as excluding "foo", but interpret "optional", "foo" and
"anything" as including "foo".

I don't know whether this would be too much for CR.

It would be better if we had a more fleshed-out system where I could say
things like "anon", "none", "foo" or email, or "email" and "foo" (but
implicitly not anon) and such, but that's definitely too much for CR. 
The best we can do is make sure that such a thing would work as an
add-on.  With the clarification above, I believe it will.


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