RE: RE: What problem are we trying to solve?

So, let's look at an example... take the case of a ReplyTo EPR that 
contains a wsa:Address of http://www.cnn.com, and a policy assertion that 
says "encrypt the message".  As far as the soap stack is concerned it 
really shouldn't need to do anything special with this EPR at all until it 
tries to talk to www.cnn.com.  Then it will encrypt the message and send 
it, right?  So, the question I have is this... why does WSA need to know 
about security?  Why are people allowed to put their own data in an EPR 
and expect that the WSA layer would undersand it?

The answer, IMO, is obvious.  It doesn't.  WSA doesn't know about security 
(per say).  Instead it provided the hooks that allow for other bits of 
code to interact with the transport mechanism - whether that be to modify 
the message before its sent or whether its to do some kind of set-up 
handshake (as in the case of sending an RM CreateSequence), it doesn't 
matter.  WSA itself doesn't need to understand what these other bits of 
code are doing.  And I believe that anon and none are (or should) be coded 
in a similar way.  They aren't really any different from www.cnn.com until 
transport layer time - and at that time the MEP changes - in a similar 
abstract way that the MEP changes when RM is turned on and a 
CreateSequence flows.   Again, we're not asking for WSA to understand 
RManonURI at all, we're asking for the hooks to allow for it to be plugged 
in, the exact way people need to plug in the other parts of RM, 
Security....

thanks,
-Doug




Jonathan Marsh <jmarsh@microsoft.com> 
Sent by: public-ws-addressing-request@w3.org
10/03/2006 06:35 PM

To
Bob Freund <bob@freunds.com>, Doug Davis/Raleigh/IBM@IBMUS
cc
"[WS-A]" <public-ws-addressing@w3.org>, 
"public-ws-addressing-request@w3.org" 
<public-ws-addressing-request@w3.org>
Subject
RE: RE: What problem are we trying to solve?






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