RE: What problem are we trying to solve?

Should I understand that message 5 is the response to message 3? Or an
acknowledgment of 3? Or that it carries (in its headers) the
acknowledgment? Perhaps if there were some indication of the meaning of
the messages / their relationships, it would give us more common ground
for discussion.
 
If I read it correctly, B's second response (202) carries the
connotation that "the response to this message (3) is not YET
available", while B's third response is Message 4 (is this an
independent and unrelated message?) + the information that a response to
message 3 is still not yet available. Is that accurate?
 
This description does make "MakeConnection" look like a polling
mechanism, although I have heard that the RM group are not fond of
hearing it described that way :-)
 
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 Alastair Green
Sent: Wednesday, 4 October 2006 9:23
To: Jonathan Marsh
Cc: Bob Freund; Doug Davis; [WS-A]; public-ws-addressing-request@w3.org;
ws-rx@lists.oasis-open.org
Subject: 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>
<mailto: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