Re: Proposal for WS-Policy assertions - thread 2

On Nov 9, 2006, at 5:53 AM, Katy Warr wrote:
>
> ** Question: Specifying 'async' only
> <wsp:Policy>
>   <wsaw:AddressingRequired/>
>   <wsaw:NonAnonymousReplies/>
> </wsp:Policy>
> Indicates all but wsa:anonymous is supported for replies.  How  
> would you specify that all URIs except(wsa:anonymous AND  
> wsfoo:anon) are supported for replies?
>
I think that would depend on the semantics of wsfoo. E.g. you might  
have a wsfoo:Required assertion similar to the proposed  
wsaw:AddressingRequired where absence of wsfoo:AonReplies means that  
wsfoo:anon isn't supported.

> ** Suggestion: Specifying full support for WS-Addressing
> In the 99% case - namely "I provide complete addressing", your  
> proposed solution requires that support for anonymous/non-anon  
> replies is explicitly stated.  I.e.
> <wsp:Policy>
>   <wsaw:AddressingRequired/>
>   <wsaw:AnonymousReplies/>
>   <wsfoo:AnonReplies/>
> </wsp:Policy>
>
Right though I'm not sure I agree that full support is the 99% case.  
I think there will remain a significant class of endpoints that only  
support anonymous.

> On a previous note, I mentioned that we should assume that the  
> target provides full WS-Addressing support (unless otherwise  
> stated).  In other words, the 'anonymous' markers should restrict  
> behaviour, not enhance it.
>
The idea was to provide positive rather than negative assertions to  
avoid the inadvertent exclusion of addresses from other SOAP  
extensions (which lead to cr33).

> So, in keeping with the core principle of your suggestion, could we  
> restructure the policy assertion so the base case is 'complete  
> support'?
> Here's a suggestion:
>
> <wsp:Policy>
>   <wsaw:AddressingRequired/>
> </wsp:Policy>
> means addressing required with *full support* for all replyTo URIs
>
> <wsp:Policy>
>  <wsaw:AddressingRequired>
>       <wsaw:ResponseURIsRestricted>
>         <wsaw:AnonymousReplies/>
>         <wsfoo:AnonReplies/>
>       </wsaw:ResponseURIsRestricted>
>    </wsaw:AddressingRequired>
> </wsp:Policy>
> means Addressing is required and supported with the restriction  
> that only anonymous URIs are supported.
>
I'm not that familiar with WS-Policy but it seems like requiring  
wsfoo to mix its assertion into the ws-addr one isn't ideal ? However  
if you don't do that then you would be left with the  
wsfoo:AnonReplies contradicting the wsaw:AddressingRequired  
restriction which is the root of the problem in cr33.

Thanks,
Marc.

> <wsp:Policy>
>   <wsaw:AddressingRequired>
>        <wsaw:ResponseURIsRestricted>
>             <wsaw:NonAnonymousReplies/>
>        </wsaw:ResponseURIsRestricted>
>     </wsaw:AddressingRequired>
> </wsp:Policy>
> means Addressing is required and supported with the restriction  
> that only non-wsa:anonymous URIs are supported.
>
> Many thanks
> Katy
>
>
>
> Marc Hadley <Marc.Hadley@Sun.COM>
> Sent by: public-ws-addressing-request@w3.org
> 08/11/2006 20:50
>
> To
> "public-ws-addressing@w3.org List" <public-ws-addressing@w3.org>
> cc
> Subject
> Proposal for WS-Policy assertions
>
>
>
>
>
> Gilbert and I took an action to propose some assertions for declaring
> WS-Addr requirements/capabilities in WS-Policy. After a bit of
> discussion we came up with the following three assertions:
>
> (i) <wsaw:AddressingRequired/> - the endpoint requires WS-Addressing,
> optionality can be conveyed using WS-Policy constructs.
>
> (ii) <wsaw:AnonymousReplies/> - the endpoint can send replies using
> WS-A anonymous; the endpoint can't send to anon if not present.
>
> (iii) <wsaw:NonAnonymousReplies/> - the endpoint can send replies
> using other addresses; the endpoint can't send to other addresses if
> not present (unless some other assertion adds a class of supported
> addresses).
>
> Assertion (iii) is deliberately vague, its presence means that a non-
> anon address might work but doesn't constrain what such an address
> might look like - a receiver can still reject an address that it
> doesn't grok or that requires a binding it doesn't support. The WG
> decided against specifying things like available response bindings so
> I think this is in line with that decision.
>
> Here are some examples:
>
> <wsp:Policy>
>   <wsaw:AddressingRequired/>
>   <wsaw:AnonymousReplies/>
> </wsp:Policy>
>
> Means that addressing is required and only anonymous replies are
> supported.
>
> <wsp:Policy>
>   <wsaw:AddressingRequired/>
>   <wsaw:NonAnonymousReplies/>
> </wsp:Policy>
>
> Means that addressing is required and only non-anonymous replies are
> supported.
>
> <wsp:Policy>
>   <wsaw:AddressingRequired/>
>   <wsaw:AnonymousReplies/>
>   <wsaw:NonAnonymousReplies/>
> </wsp:Policy>
>
> Means that addressing is required and both anonymous and non-anonymous
> replies are supported.
>
> <wsp:Policy>
>   <wsaw:AddressingRequired>
> </wsp:Policy>
>
> Wouldn't be too useful for anything other than a one-way message
> since neither anonymous nor non-anonymouse replies are supported.
>
> <wsp:Policy>
>   <wsaw:AddressingRequired/>
>   <wsaw:AnonymousReplies/>
>   <wsfoo:AnonReplies/>
> </wsp:Policy>
>
> Means that addressing is required and that anon replies as defined by
> WS-Addr or WS-Foo are supported.
>
> Marc.
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
>

---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.