Re: New Proposed Alternative H to resolve WS Policy LC comments on WSAM

What your are describing is alternative F.

We may want to to wait for the ws-policy to resolve the nested policy 
negation issue before we finally decided.

Tom

Anish Karmarkar wrote:
>
> Tom,
>
> Why not define just two nested assertions and allow then to be 
> specified together. I.e., do the following:
>
> wsam:Addressing -- says that it supports ws-addressing spec (nothing 
> more, nothing less). On its own does not say anything about anon or 
> non-anon, they may be supported, YMMV.
>
> nested assertion wsam:AnonymousResponse -- says that anonymous 
> response is supported.
>
> nested assertion wsam:NonAnonymousResponse -- says that the non-anon 
> response is supported.
>
> This is how various usecases would look like.
>
> 1) usecase 1: ws-addressing is supported (nothing more)
>
> [apologies for errors in ws-policy syntax, if any]
>
> <wsp:Policy>
>   <wsp:ExactlyOne>
>     <wsp:All>
>        <wsam:Addressing/>
>     </wsp:All>
>   </wsp:ExactlyOne>
> <wsp:Policy>
>
> 2) usecase 2: WS-addressing with guarantee that anon is supported:
>
> <wsp:Policy>
>   <wsp:ExactlyOne>
>     <wsp:All>
>       <wsam:Addressing>
>         <wsp:Policy>
>           <wsp:ExactlyOne>
>             <wsp:All>
>               <wsam:AnonymousResponse/>
>             </wsp:All>
>           </wsp:ExactlyOne>
>       </wsam:Addressing>
>     </wsp:All>
>   </wsp:ExactlyOne>
> <wsp:Policy>
>
> 3) usecase 3: ws-addressing with guarantee that non-anon is supported:
>
> <wsp:Policy>
>   <wsp:ExactlyOne>
>     <wsp:All>
>       <wsam:Addressing>
>         <wsp:Policy>
>           <wsp:ExactlyOne>
>             <wsp:All>
>               <wsam:NonAnonymousResponse/>
>             </wsp:All>
>           </wsp:ExactlyOne>
>       </wsam:Addressing>
>     </wsp:All>
>   </wsp:ExactlyOne>
> <wsp:Policy>
>
> 4) usecase 4: ws-addressing with guaranted that both anon and non-anon 
> are supported:
>
> <wsp:Policy>
>   <wsp:ExactlyOne>
>     <wsp:All>
>       <wsam:Addressing>
>         <wsp:Policy>
>           <wsp:ExactlyOne>
>             <wsp:All>
>               <wsam:AnonymousResponse/>
>             </wsp:All>
>             <wsp:All>
>               <wsam:NonAnonymousRespone/>
>             <wsp:All>
>           </wsp:ExactlyOne>
>       </wsam:Addressing>
>     </wsp:All>
>   </wsp:ExactlyOne>
> <wsp:Policy>
>
> WRT policy matching,
> 1) if one were looking for ws-addressing with a guarantee that (say) 
> anonymous was supported, one would look for a policy similar to one in 
> usecase 2.
>
> 2) if one were looking for ws-addressing with possible anon support 
> (but no guarantee), then one would look for a match for { usecase 1 OR 
> usecase 2}.
>
> -Anish
> -- 
>
> Tom Rutt wrote:
>> It seems there is quite a bit of discussion on the meaning of an 
>> empty assertion, when that assertion is defined to allow nested
>> assertion types.
>>
>> One way for wsa to totally avoid this interpretation question is to 
>> define the Addressing assertion in such a way that one
>> and only one of the following three nested assertions MUST be present 
>> in any alternative using the Addressing assertions:
>> OnlyAnonymousResponses.
>> OnlyNonAnonymousResponses
>> BothResponseTypes
>>
>> to indicate any restrictions on response EPR types.
>>
>> I attach this new proposal for discussion :
>>
>> Tom Rutt
>>
>
>

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Monday, 16 April 2007 19:51:52 UTC