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

RE: Who knows what from where?

From: Rogers, Tony <Tony.Rogers@ca.com>
Date: Wed, 25 Oct 2006 03:36:42 +1000
Message-ID: <BEE2BD647C052D4FA59B42F5E2D946B317B6AF@AUSYMS12.ca.com>
To: "Francisco Curbera" <curbera@us.ibm.com>, "David Hull" <dmh@tibco.com>
Cc: <public-ws-addressing@w3.org>, <public-ws-addressing-request@w3.org>
The part that worries me about this was Doug's recent suggestion that the RM URI was supposed to be "understood" (for some value of "understood") by non-RM-aware participants. I have no difficulty with those who are RM-aware, because they are expected to understand. I do not, however, understand how something that is not aware of RM can "understand" the URI.
Tony Rogers
CA, Inc
Senior Architect, Development
co-chair UDDI TC at OASIS
co-chair WS-Desc WG at W3C


From: public-ws-addressing-request@w3.org on behalf of Francisco Curbera
Sent: Wed 25-Oct-06 2:21
To: David Hull
Cc: public-ws-addressing@w3.org; public-ws-addressing-request@w3.org
Subject: Re: Who knows what from where?

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. 


David Hull <dmh@tibco.com> 

10/24/2006 10:51 AM 

Francisco Curbera/Watson/IBM@IBMUS 
"public-ws-addressing@w3.org" <public-ws-addressing@w3.org>, public-ws-addressing-request@w3.org 
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.


*	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.


*	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".


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 

"public-ws-addressing@w3.org" <mailto:public-ws-addressing@w3.org>  <public-ws-addressing@w3.org> <mailto:public-ws-addressing@w3.org>  
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.*' 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?
Received on Tuesday, 24 October 2006 17:41:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:14 UTC