Re: Proposal for WS-Policy assertions - thread 2

Marc

Thanks for your response.

>>
>> ** 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.
>
OK - or I guess use same pattern as wsa. 

>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.
>
There are use cases for anonymous only support, but I still believe that 
the complete ws-addressing policy assertion is by far the predominant one.
Making it the most simple would be preferential for the majority of 
implementors.

>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.
>
Yes you're right - mixing the assertions in this way would be bad.  I 
can't think of another way to simplify the 'supports all' assertion
without the contradictions that you state so perhaps we'll have to 
live with it. I guess that this is a disadvantage of defining the 
endpoint's 
capabilities to process the wsa:ReplyTo though specs other than wsa. 

regards,
Katy




Marc Hadley <Marc.Hadley@Sun.COM> 
Sent by: public-ws-addressing-request@w3.org
09/11/2006 14:56

To
Katy Warr/UK/IBM@IBMGB
cc
"public-ws-addressing@w3.org List" <public-ws-addressing@w3.org>
Subject
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.