Re: What problem are we trying to solve?

Jonathan,

Given a connection identified as X, between endpoint A (that is 
non-addressable) and endpoint B (that is addressable), I posited the 
following canonical use case in a recent posting to WS-RX:

A req: message 1, connection X, reply to anon if available.
B resp: message 2
A req: message 3, connection X, reply to anon if available
B resp: no envelope, 202, i.e. message not available
A req: MakeConnection, X
B resp: message 4, MessagePending
A req: MakeConnection, X
B resp: message 5

Net effect, for connection/conversation identified as X:

A to B: message 1
B to A: message 2
A to B: message 3
B to A: message 4
B to A: message 5

How does this match the model or use cases that create the RM requirement?

Does this express the intended use of MakeConnection?

I think this sequence is realistic, and useful, by the way.

Alastair

Jonathan Marsh wrote:
>
> I agree with Doug, that the crux of the WS-A issue is "whether or not 
> WSA will allow other specs to define new 'special' non-addressable 
> URIs."  I believe that if this point were to be used effectively as an 
> extensibility point it would have to be architected better.  We put 
> this extensibility point in at the last minute without adequate 
> consideration of its consequences.  Anish's isAnon proposal attempts 
> to architect the point better, at least in the domain of 
> anonymous-like behavior.  I can imagine extending that mechanism to an 
> "isSpecial" functionality for general-purpose special URIs (e.g. 
> synonyms for 'none').  Either of these solutions would naturally fall 
> within the Core, suggesting a new version of WS-A which is an 
> impractical solution.  The practical solution is to remove the 
> misleading suggestion in 5.2.1 that this extensibility point actually 
> can be used safely.
>
>  
>
> The core of this issue remains, of course, an WS-RM one -- namely, can 
> the desired "polling" functionality (if desired!) be achieved without 
> intruding into the WS-A layer, without bending or limiting WS-A in 
> ways that might not compose well with other uses of WS-A, and whether 
> it fully leverages the capabilities of WS-A to address messages to the 
> appropriate destinations.  I think this WG can play a role in 
> providing such advice, though that has been slowed considerably IMO by 
> the lack of clearly documented use cases and a model for how the 
> current polling solution is intended to work.
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] *On Behalf Of *Bob Freund
> *Sent:* Tuesday, October 03, 2006 3:05 PM
> *To:* Doug Davis
> *Cc:* [WS-A]; public-ws-addressing-request@w3.org
> *Subject:* RE: What problem are we trying to solve?
>
>  
>
> Doug,
>
> The list is what I heard from the folks on the call.  It is intended 
> to provoke discussion and possibly correction.
>
> The question of priority is if the exposition is the correct 
> description of the problem to be solved.
>
> There was also discussion of a potential errata that would remove 
> 5.2.1 which I did not include in my summary.
>
> For now, I would be content to have a well characterized definition of 
> the problem so that it might be bounded.
>
> Several folks have expressed reservations about synonyms for 
> anonymous.  If it is intended that anonymous identify a specific 
> resource (such as the backchannel).  It then would make as much sense 
> as defining a synonym for www.cnn.com <http://www.cnn.com/>.
>
> More than that, some folks have said that this synonym overloads 
> replyTo and defines semantics associated with a definition of this uri 
> that only RM will understand.
>
> Do you disagree with the exposition?  Does the RM redefined URI convey 
> identifying or parametric information or does it not?
>
> Thanks
>
> -bob
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Doug Davis [mailto:dug@us.ibm.com]
> *Sent:* Tuesday, October 03, 2006 5:11 PM
> *To:* Bob Freund
> *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
>  
>  
>  
>  
>  
>