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

RE: What problem are we trying to solve?

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Tue, 3 Oct 2006 17:29:30 -0700
To: Doug Davis <dug@us.ibm.com>, "bob@freunds.com" <bob@freunds.com>
CC: "[WS-A]" <public-ws-addressing@w3.org>, "public-ws-addressing-request@w3.org" <public-ws-addressing-request@w3.org>
Message-ID: <1C40239E22E8594DA37395602FC7362F474925E7@NA-EXMSG-C112.redmond.corp.microsoft.com>
"So, does the WSA WG think that no other spec, for all time, will ever need to define a new special non-addressable URI that may be used in ReplyTo/FaultTo?  (like ws-rm or ws-discovery did)"

The assertion that WS-Discovery defines URIs that are treated specially at the WS-Addressing level is untrue.  Don't conflate non-http URIs with non-addressable URIs, and assume that they must be "special" URIs that have specific behavioral consequences at the WS-Addressing level.

________________________________
From: public-ws-addressing-request@w3.org [mailto:public-ws-addressing-request@w3.org] On Behalf Of Doug Davis
Sent: Tuesday, October 03, 2006 2:11 PM
To: bob@freunds.com
Cc: [WS-A]; public-ws-addressing-request@w3.org
Subject: Re: What problem are we trying to solve?


Bob,
 A couple of points:

- A4 - if I'm reading your text right, I believe you're saying that other specs can define their own replyTo header.  And this is true.  However, this means that WSA is extensible by allowing people to avoid WSA.  Funny  :-)

- Despite all of the talk around CR33, the issue is not about transmitting identifying information.  Nor is it about whether or not identifying information should be placed in the URI or in some Reference Parameter/Property.  The issue around CR33 is whether or not WSA will allow other specs to define new 'special' non-addressable URIs and allow them to be used in the wsa:ReplyTo/FaultTo.  That's it.  It doesn't matter what the semantics of those URIs are, it doesn't matter how people are going to use them - its much simpler than that.  Can other specs do exactly what WSA did and define new URIs?  Any discussion about whether or not a spec made the right choice to do that is not relevant.  WSA needs to answer the very simple question from a more abstract point of view and once that answer is found then I think everything else will fall into place.

So, does the WSA WG think that no other spec, for all time, will ever need to define a new special non-addressable URI that may be used in ReplyTo/FaultTo?  (like ws-rm or ws-discovery did)

thanks,
-Doug



"Bob Freund" <bob@freunds.com>
Sent by: public-ws-addressing-request@w3.org

10/03/2006 09:01 AM

To

"[WS-A]" <public-ws-addressing@w3.org>

cc



Subject

What problem are we trying to solve?










This is a list of the results, as I heard them, of our discussion on 2006-10-02 related to our response to CR33

Exposition:
It seems that the desire inferred by the issue is that an endpoint would like to transmit identifying information (or perhaps some other parametric information) in a one way message, and that one way message is intended to be used to "open the backchannel" upon which may be transmitted information that is determined in part by the identifying or parametric information transmitted in the originating message.  In the specific use case presented, the issue originator proposes that this identifying or parametric information be passed in the replyTo uri as a special form of "anonymous".  CR33 states that the WS-Addressing WSDL binding CR document would create interoperability issues with their implementation since it does not permit a form of anonymous other than the literal "anonymous" to be represented in WSDL.

In the WS-Addressing Teleconference of 2006-10-02, there was a brainstorming session intended to clarify exactly what problem the WS-Addressing working group was trying to solve related to its resolution of CR33 since several proposals related to a direct response to CR33 have failed as yet to gain consensus.

Alternatives mentioned: (please feel free to come up with more if you have a better idea)

A1) During the progress of the WS-Addressing working group, a feature known as Reference Properties was removed from the original submission.  If this were to be added back, then this could be used to convey such identifying or parametric information.  This would imply changes to both rec level specifications as well as the WSDL binding.  It is not clear if these might be "breaking changes".

A2) The WS-Addressing specifications include a feature known as Reference Parameters which are created by the epr minter which are considered to be "opaque" to all but the minter.  Outside of the WS-Addressing "layer" there may be no such constraint.  Reference Parameters might be used to convey this identifying or parametric information.  Note that there is not general agreement that WS-Addressing is a "layer" or if it is a set of kit parts which may be used at any layer. This might imply a clarifying change to WS-Addressing specifications.

A3) WS-Addressing includes a feature known as "From" which contains a uri.  There are no behavioral constraints imposed by "From" and potentially anything that might be represented as a uri might be conveyed. This might imply a clarifying change to WS-Addressing specifications.

A4) WS-Addressing defined a limited set of special URLs which mean specific things to WS-Addressing when used in replyTo.  These are "anonymous" and "none".  If the behavior specified by WS-Addressing is not desired, then the authors of other specifications might specify their own forms of replyTo semantics appropriate to their application without WS-Addressing implications.  This would imply that CR33 be closed with no action.

A5) It was suggested that there is wide latitude in what might be contained in a SOAP header and the authors might be able to use such a means to convey the desired identifying or parametric information. This would imply that CR33 be closed with no action.

A6) WS-Addressing Core and SOAP binding are fine as-is, but we just need to fix the WSDL binding or perhaps come up with a WSDL cum policy related change.  For proposals related to this alternative, please refer to the issue list.

For the purposes of this thread please identify in the subject line the alternative A[1-n] referenced or "exposition" if you feel the problem statement needs improvement.

Thanks
-bob
Received on Wednesday, 4 October 2006 00:30:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:14 GMT