- From: Rogers, Tony <Tony.Rogers@ca.com>
- Date: Thu, 19 Oct 2006 12:15:42 +1000
- To: "Bob Freund" <bob@freunds.com>, "[WS-A]" <public-ws-addressing@w3.org>
- Message-ID: <BEE2BD647C052D4FA59B42F5E2D946B337574F@AUSYMS12.ca.com>
I am increasingly of the belief that we can solve the problem by specifying that the WSA anonymous URI is a prefix, and allowing other specs to append to it while retaining the "anonymity" of the URI. This solves the problem of "how does a WS-A processor know this address means to send something to the back-channel" - it can know by a simple check of the string prefix (which is neglibly more complex than the existing string comparison) - there will be no need to add extra infrastructure to handle an ever-expanding list of "anonymous URIs", which was one of my concerns. We can change the wsaw:anonymous="required" language to accept all URIs starting with the WSA anon URI (a related concern). It also allows distinguishing between the WSA anon and the RM anon - the latter would be longer :-) We can specify the full meaning of the URI without suffix (restricting the language of "backchannel of THIS message" to the unadorned URI, perhaps), and provide a somewhat looser definition for all URIs that begin with this string - perhaps even using the language that Glen suggested a long time ago: the processor "knows what to do", or some other words that do NOT specify use of the backchannel, thus returning to the original idea that the entity addressed by this URI is not addressable via a non-anonymous URI, or something along those lines. It doesn't solve the whole RM problem, but I believe it solves the WSA parts, and we can (and should) leave the rest up to the RM group. Tony Rogers tony.rogers@ca.com <blocked::mailto:tony.rogers@ca.com> ________________________________ From: public-ws-addressing-request@w3.org [mailto:public-ws-addressing-request@w3.org] On Behalf Of Bob Freund Sent: Wednesday, 18 October 2006 23:48 To: [WS-A] Subject: What Problem are we trying to solve Rev 1 note new A7 This is a list of the results, as I heard them, of our discussion on 2006-10-02 related to our response to CR33 and amended based on the discussions of the 2006-10-09 distributed meeting 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. A7) The usage scenario can be accomplished through the use of wsa:RelatesTo in conjunction with the wsa:RelationshipType extensibility point provided in the WS-Addressing core specification to define a domain specific relationship type. This option requires no change to the rec level documents. 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. Miscellaneous comments: It seems that there is at least two areas of the WS-Addressing specs that might be clarified once we see our way through this maze. 1) Usage of the words reply and response seem to be variously interpreted to mean the specific application response to THIS message rather than a returned soap body that was stimulated by THIS message but that might relate to some other message. 2) If the WG settles on a rejection of section 5.2.1 advice concerning the potential of other forms of anonymous then that section ought to be amended accordingly. Conversely if the WG re-affirms that section, then it ought to embrace that decision appropriately in the WSDL binding such that full use of the core and SOAP bindings are supported. Thanks -bob
Received on Thursday, 19 October 2006 02:17:02 UTC