Re: Who knows what from where?

I completely agree that a client ought only to use special features that
its tooling supports, so in particular don't use the RM anon URI if you
don't support RM.  That's fine.  My concern here is about throwing
everything that might use a "backchannel" into one "backchannel" pot.

If I advertise WSASupported or WSASupportedUsingBackchannel and nothing
else, this means that you can send me a request as a SOAP request
message and I can (or only can) send you back a response in the SOAP
response.

As I understand it, if I advertise WSAS or WSASUB /and/ I advertise "I
support RM", I'm saying that I can handle the standard anon /and/ I'm
saying that I support the RM anon with its behavior of using /later/
SOAP responses.  This is clearly not an obvious consequence, and I agree
it would need to be mentioned in the RM spec.  Conversely, an
implementation doesn't have the option of just supporting one; it will
always have to support both.  In the case of RM, this probably isn't a
burden, but that's not a trivial result either. It needs to be checked.

If some later spec, call it WS-FOO, wants to make use of the backchannel
in yet another way, then it seems reasonable that advertising support
for WS-FOO and advertising WSAS or WSASUB means supporting WS-FOO's use
of backchannel.  If you support both WS-FOO and RM, backchannel support
is an all-or-nothing deal.  I can't say (without defining more
assertions) "I can do plain vanilla anon, and RM's anon, but not
WS-FOO's variant", or any of the other six possibilities in the middle.

Granted, it seems reasonable that they wouldn't interfere with each
other and that if you can do plain anon you can also do the others, but
that's just something that seems reasonable.  It would need to be
checked.  It doesn't seem like the kind of assumption one would make
without a compelling reason, and there is none here.  Anything you can
do with a backchannel marker you can also do just by referring to
address URI directly.

If we can say specifically "I allow WSA anon", "I allow WS-RM anon" and
"I allow WS-FOO's magic URI" as separate statements, then we know that
the server can always say clearly and simply what works.  This seems
particularly useful in cases where combining two options is possible but
more work than some implementations will want to do.


Francisco Curbera wrote:
>
> I don't think every spec that uses the (or a) backchannel needs to
> define it, or even use the word itself. As long as WS-A is clear about
> what 'backchannel' means for the protocols at hand, and the binding of
> WS-A to each new protocol with backchannel capabilities defines it as
> well, clients are ok. Again, clients don't go fishing for random URLs,
> so they don't need to check them for "backchannel-ness". Instead,
> clients decide to support a set of specs (WS-A, RM, etc.) that define
> policy assertions and URLs among many other things. A client is
> supposed to understand what those definitions mean, otherwise it
> should not use them.
>
> Paco
>
>
>
> *David Hull <dmh@tibco.com>*
>
> 10/24/2006 10:51 AM
>
> 	
> To
> 	Francisco Curbera/Watson/IBM@IBMUS
> cc
> 	"public-ws-addressing@w3.org" <public-ws-addressing@w3.org>,
> public-ws-addressing-request@w3.org
> Subject
> 	Re: Who knows what from where?
>
>
>
> 	
>
>
>
>
>
> Francisco Curbera wrote:
>
> Supposedly, if the client knows about RM it also knows about the RM
> anon URI as well and what it implies wrt the use of the backchannel,
> so I really don't see the difference.
> The RM anon URI is defined explicitly in the RM spec.  The term
> "backchannel" doesn't appear to be defined anywhere.  Leaving the
> client to make an inference with respect to an undefined term seems
> risky, to say the least.  I think Marc got it right in saying that the
> RM spec would have to provide the definition.
>
> Compare:
>
>     * RM says what _"http://...wsrm/anonymous?id=...1"_
>       <http://...wsrm/anonymous?id=...1> means.
>     * The policy assertions say I can put that in my response endpoint.
>
> with
>
>     * RM says what _"http://...wsrm/anonymous?id=...1"_
>       <http://...wsrm/anonymous?id=...1> means.
>     * The policy assertions say the server can send responses on the
>       backchannel
>     * RM says, e.g., that in the context of RM, backchannel means
>       regular anon or RM anon
>
> In the third bullet, we're basically composing two specs (WSA and RM)
> that have a notion of backchannel.  I wonder how this would scale to
> composing another spec that also had such a notion.
>
> It seems better to worry about whether something is defined and
> allowed than whether it constitutes a "backchannel".
>
>
>
> Paco
>
>
> *David Hull **_<dmh@tibco.com>_* <mailto:dmh@tibco.com>
> Sent by: _public-ws-addressing-request@w3.org_
> <mailto:public-ws-addressing-request@w3.org>
>
> 10/23/2006 05:35 PM
>
> 	
> To
> 	_"public-ws-addressing@w3.org"_ <mailto:public-ws-addressing@w3.org>
> _<public-ws-addressing@w3.org>_ <mailto:public-ws-addressing@w3.org>
> cc
> 	
> Subject
> 	Who knows what from where?
>
>
>
>
> 	
>
>
>
>
>
>
>
> Pursuant to CR33:
>
> If I'm a client and I know about WS-RM, and the server says "I support
> WS-RM and you can use '_http://.../RMAnon.*_ <http:/>' in a response
> endpoint",
> then I know immediately that I can use this facility.  If the server
> says "I support WS-RM and I can send responses on the backchannel", then
> I need to know, from somewhere, that "backchannel" in this case is
> referring to the special WS-RM URI family.
>
> Where would this information appear?
>
>
>
>