Re: What problem are we trying to solve?

Marc,
  This is off-topic for CR33 but I do think there has been much confusion 
around why RM did what they did and hopefully what follows will help 
people's understanding of RM's thinking behind their decision.

  The issue of whether or not we could have used the WSA Anon came down to 
two points.  First, WSA is pretty clear that anon means the current 
connection's backchannel.  There wasn't unanimous consensus that extending 
it to mean some subsequence backchannel was allowed. There are two cases 
here, one where the original backchannel is gone (an error condition), and 
since we're in an error case WSA's rules no longer apply, RM kicks in and 
it (rm) can define whatever semantics it wants at that point.  The other 
case though doesn't involved an error condition, rather the original 
backchannel was used for something other than the application response - 
e.g. an RM CreateSequence needed to flow.  Would it then be ok for the app 
response to flow on a subsequence http response flow?  As I said, there 
was no unanimous agreement that it would be ok to reinterpret WSA's Anon 
semantics in this way.
  The other reason for defining a new URI is for identity.  We needed a 
mechanism by which we could correlate (or identify) anonymous endpoints. 
When a MakeConnection came into the server and it looked for possible 
messages to send back we needed some way for us to locate messages 
targeted to that anonymous client.  Here, again, there were several 
issues.  First, with all of the heated discussions around EPRs and 
identity it was felt that it would be safest to limit identity to just the 
wsa:Address portion of the EPR.  This is very consistent with how we think 
people are using EPR's today - the wsa:Address identifies the 
endpoint/resource of interest - the ref-p's are not part of that equation, 
rather once they're turned into Headers they are there to help the 
receiver of that message do its proper processing/routing.  And this then 
relates to the another issue related to using ref-p's - should the sender 
of the message that has these ref-p's as soap headers be expected to do 
anything with those headers?  This would be getting into some new 
territory for implementations.  Asking an endpoint to look at anything 
other than the wsa:To address of an outgoing message was felt to be a 
change to the current WSA processing model (if not soap itself) and we 
tried very hard to not change either one of those.
  So, given all of these questions (and there were probably more but I 
think these were key) we felt that rather they trying to 
overload/reinterpret Anon, or trying to change the processing model for 
outgoing messages, we could simply follow WSA's lead and define a new URI 
and assign whatever semantics we wanted w/o fear of clashing with people's 
current understanding of an existing URI.

This then brings us back to our subject line "what problem are we trying 
to solve?"  While questioning the need for RM to define a new URI is a bit 
related to CR33, it is not at the heart of the issue.  At some point in 
the future of Web Services someone may need to define some new target 
address whose semantics do not exactly match those of Anonymous or None, 
and the current WSDL marker does not allow for this possibility.  So, IMO, 
CR33 is simply about whether or not WSA will allow for this flexibility in 
the future. 

Hope this helps.

thanks
-Doug


Marc.Hadley@Sun.COM wrote on 10/06/2006 10:41:05 AM:

> On Oct 5, 2006, at 6:56 PM, Doug Davis wrote:
> >
> > Nope not in the slightest :-)
> > The replyTo on the application message is treated just like any other
> > replyTo - its where replies go.
> >
> > To "select which 'pending'" messages, there's a wsrm:Address field
> > as a child of the MakeConnection element, which goes in the Body.
> >
> In that case why doesn't RM just use the WS-A defined anonymous URI 
> for the ReplyTo ? Use of the HTTP response already provides the 
> correlation you need to tie the response to the wrm:Address you 
> supply in the request. If that isn't sufficient then RM could mandate 
> an additional SOAP header in the response that echos the value back.
> 
> Marc.
> 
> >
> > Marc Hadley <Marc.Hadley@Sun.COM>
> > Sent by: Marc.Hadley@Sun.COM
> > 10/05/2006 02:35 PM
> >
> > To
> > Doug Davis/Raleigh/IBM@IBMUS
> > cc
> > Bob Freund <bob@freunds.com>, "[WS-A]" <public-ws- 
> > addressing@w3.org>, public-ws-addressing-request@w3.org
> > Subject
> > Re: What problem are we trying to solve?
> >
> >
> >
> >
> >
> > On Oct 4, 2006, at 2:43 AM, Doug Davis wrote:
> > >
> > > > 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.
> > >
> > > It doesn't overload ReplyTo any more than switching from
> > > http://www.cnn.com   to  smtp://cnn.com   overloads it.
> > > There are transport level semantics associated with each URI
> > > that relate to how the message is transferred from one endpoint
> > > to the other. The semantics of ReplyTo are totally unchanged when
> > > the RM anon URI is used.  It still means it contains the EPR of
> > > the destination endpoint for replies.
> > >
> > Perhaps I misunderstood, but I thought that the value of the ReplyTo/
> > Address was used by RM to select which "pending" reply messages
> > should be sent, not just where they are sent. AIUI, this is the
> > overloading being referred to.
> >
> > Marc.
> >
> > ---
> > Marc Hadley <marc.hadley at sun.com>
> > Business Alliances, CTO Office, Sun Microsystems.
> >
> >
> >
> 
> ---
> Marc Hadley <marc.hadley at sun.com>
> Business Alliances, CTO Office, Sun Microsystems.
> 
>