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

Tom Rutt wrote:
> 
> 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.
> 

+1

> 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
>>>
>>
>>
>

Received on Monday, 16 April 2007 21:39:12 UTC