Re: Proposal for WS-Policy assertions

On Nov 8, 2006, at 11:36 PM, David Hull wrote:

> This looks pretty good.  In particular (unless I missed something)  
> it ought to lay CR33 well and truly to rest.  A couple of questions:
> Do we mean "replies" or "responses"?  That is, does the policy  
> apply to [reply endpoint] or to it and [fault endpoint] collectively.

Core section 3.4 uses reply to mean both normal and fault messages.  
The intent was for the assertion to apply to both [reply endpoint]  
and [fault endpoint].

>   If the latter, is there any need to slice more finely ("This is  
> OK for replies but not for faults")?  I don't see an obvious use  
> case, but it seems worth asking.  If it applies to both, I would  
> recommend changing the name to reflect that.
> I'm not greatly bothered if we don't define a means of saying "I  
> can send replies via email" and such as long as there's clearly  
> room to do so.  I can see at least two with the proposed scheme:
> Allow an {any} extension point for children of NonAnonymousReplies,  
> so you could say something like <wsaw:NonAnonymousReplies> ...  
> something that means "email spoken here" ... </ 
> wsaw:NonAnonymousReplies>.  The wsfoo:clause mentioned below might  
> slot in here, too.
> Follow the example below for wsfoo: and just define a new clause  
> for "email spoken here".

Right.

> Do you (or does anyone else) have a preference or other  
> possibility?  I'm not sure which I prefer.  The idea behind (1) is  
> to group all the assertions about non-anon replies together.  A  
> client that was only interested in anon, for example, could then  
> just look for the anon marker and know it could safely ignore  
> anything under non-anon, while it could not safely ignore other  
> assertions that were siblings to anon/non-anon.
>
I'd prefer the simplest thing that could possibly work.

Marc.

>
> Marc Hadley wrote:
>> 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.