Re: What problem are we trying to solve?

[Christopher B Ferris <chrisfer@us.ibm.com>]

Dave,

Please see my comments inlined below.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 377 9295

public-ws-addressing-request@w3.org wrote on 10/04/2006
12:24:02 AM:

> This looks like piggybacking.  I send you what you've got as
> requests, you send me whatever you've got (if anything) as 
> responses.  Given that a given server may be doing this with
> multiple clients, it's important to know which client the server is
> talking to.
> 
> There is a big long high-heat/light-ratio thread someplace 
> discussing whether this is kosher HTTP.  On the one hand, the
fact 
> that we're talking about client/server interaction on the one hand
> and independent message flows on the other suggests that it's not.
 
> On the other hand, you can view this as the client transferring a
> resource (its current message or messages) to the server and the 
> server is transferring a resource (its current message or messages
> bound for the client) back.  Let's assume it's either kosher
or we don't care.
> 
> My personal feeling is that while there may well be such a thing as
> a non-addressable endpoint, denoting a non-addressable endpoint with
> a URI or EPR is at least on the face of it a contradiction in terms.

Maybe non-addressable is a misnomer. It is not directly
accessible
by the sending endpoint by means of establishing a
protocol connection
using the identifier as an address is what it really
is.

There are many resources for which there is either
a) no representation
or b) for which no implicit means is provided for
a "client" to
access the resource directly by means of using the
URI as a protocol
address, etc. (e.g. in the urn: case). The fact that
such resources
have been identified using a URI does not make them
any less real
in the sense that they are identified resources.

> I'd seriously consider doing what we didn't and introducing a "send-
> messages-bound-for-the-client-in-the-response-messages" flag.
 It 

I presume you mean as a SOAP header block? e.g.

<wsrm:FriendsRomansCountrymenSendMeYourMessages
for="urn:uuid:yaddayadda"/>

where "urn:uuid:yaddayadda" is the identifier
of the RMD resource?

> just seems clearer to say "do this" as opposed to "send
the messages
> to this address, where this address isn't an address like any other,
> it just means 'do this'".
> 
> Defining magic URI makes the syntax more uniform, but I'm not 
> convinced that this is always a feature.
> cp $1 /temp/foo
> cp $2 $1
> cp /temp/foo $2
> rm /temp/foo
>   
> A harmless waste of bandwidth, no?  Say
$1=my-very-important-file 
> and $2 = /dev/null?  Everything's a file, right?
> 
> I suppose the other argument for using anon in such cases is to 
> leverage our notion of "backchannel".  But after much
discussion we 
> finally decided that not only does anonymous not mean "anonymous"
in
> the sense of anything that can't be named, it also doesn't refer to
> a "backchannel resource" as such.  Rather it indicates
that, in the 
> case where a message with [reply endpoint] or [fault endpoint] 
> anonymous is sent as the request half of a SOAP request-response,
> the reply (or fault, as the case may be) goes in the response half.
> 
> This isn't directly usable.  What is directly usable is the notion
> of a response message in a SOAP request-response MEP.  Again,
RM 
> (RX?) can use this notion directly via a "use the response message,
> Luke" flag, without having to define a new URI or expand the
> definition or syntax of an existing URI.
> 
> 
> Alastair Green wrote: 
> 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.
> 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 
>   
>   
>   
>   
>