Re: New Proposed Alternative D to resolve WS addr metadata LC comment

Hi,

I concur that it is troublesome that the two policies Tom is quoting do 
not intersect. Nested assertions are meant to qualify the behavior of 
the encapsulating assertion and should not cause any issue when 
intersecting with an assertion with the same QName that does not contain 
nested policies. I don't see any reason why these policies should not be 
allowed to intersect. I reviewed earlier versions of WS-SecurityPolicy 
and WS-Policy but none seem to consider this case.

Fabian


Tom Rutt wrote:
> while changing the examples for both proposals A and C I noticed a 
> troublesome aspect
> of the nested addressing assertions with respect to the default 
> intersection algorithm..
>
> In either alternative C, where absence of a nested assertion means 
> nothing, it
> seems troublesome that an addressing assertion with no nested policy 
> alternatives:
>
> <wsp:Policy>
>    <wsam:Addressing>
>        <wsp:Policy/>
>    </wsam:Addressing>
> </wsp:Policy>
>
> has a null intersection with one that has no empty nested alternative 
> (e.g
> <wsp:Policy>
>    <wsam:Addressing>
>        <wsp:Policy>
>            <wsp:ExactlyOne>
>                <wsam:AnonymousResponses/>
>                <wsam:NonAnonymousResponses/>
>            </wsp:ExactlyOne>
>        </wsp:Policy>
>    </wsam:Addressing>
> </wsp:Policy>
>
> This intersection outcome makes a little more sense with Proposed 
> alternative A (where absence implies prohibition), but I am not sure 
> why anyone would every want to prohibit both kinds of response.  Thus 
> the example with no nested assertions seems useless for if Proposed 
> alternative A is accepted.   In fact, another problem with Proposed 
> option A is that there seems to be no difference in an alternative 
> with AnonymousResponses absent and one with NonAnonymousResponses 
> present!
>
> If a response sender is not behind a firewall, then it is of little 
> value to be able to signal
> a requirement for either non anon or Anon Replies, since the cost of 
> supporting both is small.
> such a response sender would most lkely always have both alternatives 
> in their nested Addressing assertion.
>
> The more typical case is the response receiver is behind a firewall.   
> It can indicate the need for anonymous responses by only including 
> anonymous URI in its response EPRs.  It does not need a policy for this. 
> However we have defined these nested assertions as being attached to 
> the response sender.  I am having trouble coming up with realistic use 
> cases for a response sender needing to assert requirments on the types 
> of response EPRs the request sender must use.
>
> After thinking how to resolve the difficulties cited above for either 
> Alternative A or C, I came up with a sudden realization for a new 
> alternative proposal D.
>
> Alternative proposal D is to simply delete sections 3.2.1 thru 3.1.5.
>
> That is, do not define any nested policy assertions for the Addressing 
> assertion.
>
>

Received on Tuesday, 6 March 2007 13:29:18 UTC