Re: Proposal for WS-Policy assertions

On Nov 9, 2006, at 10:28 AM, David Illsley wrote:

> Hi Marc, I have a few of questions:
> 1. Are these flags supposed to be proscriptive i.e. do we define  
> behaviour
> if the server receives a response EPR which does not conform?

We define the InvalidAddress fault that is available to receivers  
should they receive a message containing an address they are not  
happy with. I don't think we require an endpoint to advertise all its  
capabilities, we just provide the mechanism to do so if they wish so  
I don't think we'd require and endpoint to send a fault if it  
receives an EPR with an address that doesn't match the ones that its  
policy advertises support for.

> 2. I assume the RM-Anon isn't supported/allowed if there is just a
> wsaw:AnonymousReplies?

Right.

> 3. I assume that, per the resolution of CR32, in the absence of
> wsaw:AnonymousReplies or wsaw:NonAnonymousReplies, the none-uri is
> supported (indeed logically is the only supported/allowed address to
> send)?
>

Right.

Marc.

>
> public-ws-addressing-request@w3.org wrote on 11/08/2006 08:50:58 PM:
>
>> 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.