Re: WS-A Action Item: proposal for use of policy - correction

Tom Rutt wrote:
I made an error in the B intersect C analysis.  This correction now 
agrees with Tony's original
conclusion.

I made a cut and paste error, the corrections to section 3 are shown are 
inline.

The corrected analysis is attached as a text file.
> Rogers, Tony wrote:
>> I added the editorial note to 3.1.4.
>> Below is some suggested language to disentangle the confusion.
>> === making the meaning of the policy assertions clearer ===
>> Taking section 3.1.2 as our example (3.1.3 is identical in 
>> structure). Current content reads:
>>
>> The wsam:AnonymousResponses element MAY be used as a policy assertion 
>> nested within the wsam:Addressing assertion in accordance with the 
>> rules laid down by WS-Policy Framework 1.5 section 4.3.2. The 
>> appearance of this element within a policy alternative indicates that 
>> the endpoint will accept request messages with response endpoint EPRs 
>> that contain the anonymous URI 
>> ("http://www.w3.org/2005/08/addressing/anonymous") as the value of 
>> [address]. The absence of the wsam:AnonymousResponses policy 
>> assertion within a policy alternative does *not* indicate that the 
>> endpoint will not accept request messages with response endpoint EPRs 
>> that contain the anonymous URI as an address; it simply indicates the 
>> lack of any affirmation of support for anonymous URIs.
>>
>> I propose that we change this to:
>>
>> The wsam:AnonymousResponses element MAY be used as a policy assertion 
>> nested within the wsam:Addressing assertion in accordance with the 
>> rules laid down by WS-Policy Framework 1.5 section 4.3.2.
>>
>> The appearance of this element within a policy alternative indicates 
>> that the endpoint expresses explicit support for request messages 
>> with response endpoint EPRs that contain the anonymous URI 
>> ("http://www.w3.org/2005/08/addressing/anonymous") as the value of 
>> [address]. An alternative interpretation is that the endpoint 
>> guarantees support for anonymous responses.
>>
>> The absence of the wsam:AnonymousResponses policy assertion within a 
>> policy alternative does *not* indicate that the endpoint will not 
>> accept request messages with response endpoint EPRs that contain the 
>> anonymous URI as an address; it simply indicates the lack of any 
>> affirmation of support for anonymous URIs.
>>
> I think this new wording is more precise. I like it.
>> === clarifying use of policy intersection to find compatible policy ===
>> This is new language - it might make a good replacement or extension 
>> for 3.1.4:
>> If a client is looking for an endpoint with compatible policy, one 
>> common method used is to take the policy intersection between the 
>> policy the client is looking for and the policy asserted in the WSDL. 
>> The policy used by the client for this purpose must be written 
>> carefully to avoid unexpected results. Note in particular that a 
>> client which does not require explicit support for anonymous 
>> responses should use a policy assertion which includes 
>> wsam:AnonymousResponses, marked as optional - failing to do so could 
>> mean missing a compatible policy. The same applies to 
>> wsam:NonAnonymousResponses.
> The following analysis verifies the policy intersection for the three 
> policy expressions
> (A, B, and C)From Tony’s Example.
>
> It also introduces an example using the ignorable attribute.
>
> Section 1 reproduces Tony’s example.
> Section 2 shows the intersection of A with B
> Section 3 shows the intersection of C with B
> Section 4 introduces a new example policy expression D,
> which uses the ignorable attribute, and shows the Lax intersection of 
> A with D.
>
> -------
> 1 Example from Tony:
> “
> Example:
> If the client does not require explicit support for anonymous responses,
> but does require WS-Addressing, and uses Policy Assertion A:
>
> <wsp:Policy>
> <wsam:Addressing>
> <wsp:Policy/>
> </wsam:Addressing>
> </wsp:Policy>
>
> (client is looking for Addressing required, but is not concerned about 
> explicit
> support for anonymous responses)and the WSDL contains Policy Assertion B:
>
> <wsp:Policy>
> <wsam:Addressing>
> <wsp:Policy>
> <wsam:AnonymousResponses/>
> </wsp:Policy>
> </wsam:Addressing>
> </wsp:Policy>
>
> (WSDL expresses Addressing required, offers explicit support for 
> anonymous
> responses) then the policy intersection will be empty, and the client 
> will miss
> a compatible endpoint.
>
> The client's policy assertion should read: (Policy Assertion C:
>
> <wsp:Policy>
> <wsam:Addressing>
> <wsp:Policy>
> <wsam:AnonymousResponses wsp:Optional="true"/>
> </wsp:Policy>
> </wsam:Addressing>
> </wsp:Policy>
>
> “
>
> -------
>
> 2 Intersection of A with B
>
> Normalized Policy Expression A:
>
> <wsp:Policy>
> <wsp:ExactlyOne>
> <wsp:All> <!— Alternative A1 -->
> <wsam:Addressing>
> <wsp:Policy>
> <wsp:ExactlyOne>
> <wsp:All/> <!— inner Alternative A2 -->
> </wsp:ExactlyOne>
> </wsp:Policy>
> </wsam:Addressing?
> </wsp:All>
> </wsp:ExactlyOne>
> </wsp:Policy>
>
> Normalized Policy Expression B:
>
> <wsp:Policy>
> <wsp:ExactlyOne>
> <wsp:All> <!— Alternative B1 -->
> <wsam:Addressing>
> <wsp:Policy>
> <wsp:ExactlyOne>
> <wsp:All> <!— inner Alternative B2 -->
> <wsam:AnonymousResponses/>
> </wsp:All>
> </wsp:ExactlyOne>
> </wsp:Policy>
> </wsam:Addressing?
> </wsp:All>
> </wsp:ExactlyOne>
> </wsp:Policy>
>
>
> Assertions A1 and B1 each contain a nested policy expression.
>
> The inner nested alternative of A is (A2):
> <wsp:All>
> <wsam:AnonymousResponses/>
> </wsp:All>
>
> and the inner nested alternative of B is (B2):
> <wsp:All/>
>
> By the following rule from WS Policy:
> http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.html?content-type=text/html;%20charset=utf-8#Policy_Intersection 
> :
> “
> *If the mode is strict, two policy alternatives A and B are compatible:
> o if each assertion in A is compatible with an assertion in B, and
> o if each assertion in B is compatible with an assertion in A.
> “
> A2 and B2 are not compatible (since an assertion in A2 is not 
> compatible with
> any assertion in B2).
>
> By the following rule from WS Policy:
> “
> * Two policy assertions are compatible if they have the same type and
> * If either assertion contains a nested policy expression, the two
> assertions are compatible if they both have a nested policy expression 
> and the
> alternative in the nested policy expression of one is compatible with the
> alternative in the nested policy expression of the other.
> “
> it follows that nested policy assertions A1 and B1 are not compatible, 
> because
> A2 and B2 are not compatible.
>
> By the following rule from WS Policy:
> “
> * Two policies are compatible if an alternative in one is compatible 
> with an
> alternative in the other. If two policies are compatible, their 
> intersection is
> the set of the intersections between all pairs of compatible 
> alternatives,
> choosing one alternative from each policy. If two policies are not 
> compatible,
> their intersection has no policy alternatives.
> “
> it follows that policy A and B are not compatible since there is no 
> alternative
> in A compatible with an alternative in B.
>
> Thus A Intersect B has no alternatives:
>
> ----------
>
> 3 Intersection of C with B:
>
> Normalized Policy Expression C:
> <wsp:Policy>
> <wsp:ExactlyOne>
> <wsp:All> <!— Alternative C1 -->
> <wsam:Addressing>
> <wsp:Policy>
> <wsp:ExactlyOne>
> <wsp:All> <!— inner Alternative C2 -->
> <wsam:AnonymousResponses/>
> </wsp:All>
> <wsp:All/> <!— inner Alternative C3 -->
> </wsp:ExactlyOne>
> </wsp:Policy>
> </wsam:Addressing?
> </wsp:All>
> </wsp:ExactlyOne>
> </wsp:Policy>
>
> Normalized Policy Expression B:
> <wsp:Policy>
> <wsp:ExactlyOne>
> <wsp:All> <!— Alternative B1 -->
> <wsam:Addressing>
> <wsp:Policy>
> <wsp:ExactlyOne>
> <wsp:All> <!— inner Alternative B2 -->
> <wsam:AnonymousResponses/>
> </wsp:All>
> </wsp:ExactlyOne>
> </wsp:Policy>
> </wsam:Addressing?
> </wsp:All>
> </wsp:ExactlyOne>
> </wsp:Policy>
>
> Assertions C1 and B1 each contain a nested policy expression.
>
> The inner nested alternatives of C are (C2):
> <wsp:All>
> <wsam:AnonymousResponses/>
> </wsp:All>
> and (C3)
> <wsp:All/> <!— inner Alternative C3 -->
> while, the inner nested alternative of B is (B2):
The following line is erroneous
> <wsp:All/>
the correct B2 is as follows:

            <wsp:All> <!— inner Alternative B2 -->
              <wsam:AnonymousResponses/>
            </wsp:All>

>
> C3 and B2 are compatible since each is an empty alternative.
The above line should read:
C3 and B2 are compatible since each has an identical assertion.
>
> By application of the other rules the intersection of C and B is as 
> follows:
> <wsp:Policy>
> <wsp:ExactlyOne>
> <wsp:All>
> <wsam:Addressing>
> <wsp:Policy>
> <wsp:ExactlyOne>
the following line is erroneous
> <wsp:All/> <!— intersection of C3 and B2 -->
the above line should be replaced with the following
            <wsp:All> <!— intersection of C3 and B2 -->
              <wsam:AnonymousResponses/>
            </wsp:All>
> </wsp:ExactlyOne>
> </wsp:Policy>
> </wsam:Addressing?
> </wsp:All>
> </wsp:ExactlyOne>
> </wsp:Policy>
>
> which happens to be equivalent to policy expression A.
the above line should state
which appens to be equivalent to policy expression B.

>
> ------
>
> 4 Use of Ignorable attribute
>
> Lets try another policy Expression D, which uses the Ignorable Attribute:
> <wsp:Policy>
> <wsam:Addressing>
> <wsp:Policy>
> <wsam:AnonymousResponses wsp:Ignorable="true"/>
> </wsp:Policy>
> </wsam:Addressing>
> </wsp:Policy>
>
> Normalized Policy Expression D:
> <wsp:Policy>
> <wsp:ExactlyOne>
> <wsp:All> <!— Alternative D1 -->
> <wsam:Addressing>
> <wsp:Policy>
> <wsp:ExactlyOne>
> <wsp:All> <!— inner Alternative D2 -->
> <wsam:AnonymousResponses wsp:Ignorable=”true”/>
> </wsp:All>
> </wsp:ExactlyOne>
> </wsp:Policy>
> </wsam:Addressing?
> </wsp:All>
> </wsp:ExactlyOne>
> </wsp:Policy>
>
> By application of the following rule for Lax Intersection Algorithm 
> from WS Policy:
> “
> - If the mode is lax, two policy alternatives A and B are compatible:
> * if each assertion in A that is not an ignorable policy assertion is
> compatible with an assertion in B, and
> * if each assertion in B that is not an ignorable policy assertion is
> compatible with an assertion in A.
>
> If two alternatives are compatible, their intersection is an alternative
> containing all of the assertions in both alternatives.
> “
> A2 and D2 are Lax compatible, and the Lax intersection of A2 with D2 is:
> <wsp:All> <!— A2 intersectLax D2 -->
> <wsam:AnonymousResponses wsp:Ignorable=”true”/>
> </wsp:All>
>
> Note that if the wsdl policy supports expression D, and the client 
> supports
> expression A, their lax intersection (A intersectLax D) is:
>
> <wsp:Policy>
> <wsp:ExactlyOne>
> <wsp:All>
> <wsam:Addressing>
> <wsp:Policy>
> <wsp:ExactlyOne>
> <wsp:All> <!— D2 intersectLax A2 -->
> <wsam:AnonymousResponses wsp:Ignorable=”true”/>
> </wsp:All>
> </wsp:ExactlyOne>
> </wsp:Policy>
> </wsam:Addressing?
> </wsp:All>
> </wsp:ExactlyOne>
> </wsp:Policy>
>
> Note that if the wsdl policy supports expression D, and the client 
> supports
> expression A,their lax intersection is equivalent to expression D.
>
> I think this is a better alternative than having the WSDL support B 
> and the
> client supporting C. In the end the client will have an intersected 
> policy
> which includes the ignorable assertion for anonymousResponses.
>
>
> Tom Rutt
>


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

This email verifies the policy intersection for the three policy expressions 
(A, B, and C)From Tony’s Example.

It also introduces an example using the ignorable attribute.

Section 1 reproduces Tony’s example.
Section 2 shows the intersection of A with B
Section 3 shows the intersection of C with B (note this has a correction from 
the earlier mail.
Section 4 introduces a new example policy expression D, 
which uses the ignorable attribute, and shows the Lax intersection of A with D.

-------
1  Example from Tony: 
“
Example:
If the client does not require explicit support for anonymous responses, 
but does require WS-Addressing, and uses Policy Assertion A:
 
<wsp:Policy> 
    <wsam:Addressing> 
        <wsp:Policy/> 
    </wsam:Addressing> 
</wsp:Policy>
 
(client is looking for Addressing required, but is not concerned about explicit 
support for anonymous responses)and the WSDL contains Policy Assertion B:

<wsp:Policy>
    <wsam:Addressing>
        <wsp:Policy>
            <wsam:AnonymousResponses/>
        </wsp:Policy>
    </wsam:Addressing>
</wsp:Policy>

(WSDL expresses Addressing required, offers explicit support for anonymous 
responses) then the policy intersection will be empty, and the client will miss 
a compatible endpoint. 

The client's policy assertion should read: (Policy Assertion C:
 
<wsp:Policy> 
    <wsam:Addressing> 
        <wsp:Policy> 
            <wsam:AnonymousResponses wsp:Optional="true"/> 
        </wsp:Policy> 
    </wsam:Addressing> 
</wsp:Policy>
 
“

-------

2 Intersection of A with B

Normalized Policy Expression A:

<wsp:Policy>
  <wsp:ExactlyOne>
    <wsp:All> <!— Alternative A1 -->
      <wsam:Addressing>
        <wsp:Policy>
           <wsp:ExactlyOne>
              <wsp:All/> <!— inner Alternative A2 -->
           </wsp:ExactlyOne>
        </wsp:Policy>
      </wsam:Addressing?
    </wsp:All> 
  </wsp:ExactlyOne>
</wsp:Policy>

Normalized Policy Expression B:

<wsp:Policy>
  <wsp:ExactlyOne>
    <wsp:All> <!—  Alternative B1 -->
      <wsam:Addressing>
        <wsp:Policy>
          <wsp:ExactlyOne>
            <wsp:All> <!— inner Alternative B2 -->
              <wsam:AnonymousResponses/>
            </wsp:All> 
          </wsp:ExactlyOne>
        </wsp:Policy>
      </wsam:Addressing?
    </wsp:All> 
  </wsp:ExactlyOne>
</wsp:Policy>


Assertions A1 and B1 each contain a nested policy expression.

The inner nested alternative of A is (A2):
            <wsp:All> 
              <wsam:AnonymousResponses/>
            </wsp:All> 

and the inner nested alternative of B is (B2):
            <wsp:All/>

By the following rule from WS Policy: 
http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-
framework.html?content-type=text/html;%20charset=utf-8#Policy_Intersection :
“
*If the mode is strict, two policy alternatives A and B are compatible: 
    o	if each assertion in A is compatible with an assertion in B, and
    o	if each assertion in B is compatible with an assertion in A.
“
A2 and B2 are not compatible (since an assertion in A2 is not compatible with
any assertion in B2).

By the following rule from WS Policy:
“
*	Two policy assertions are compatible if they have the same type and
*	If either assertion contains a nested policy expression, the two 
assertions are compatible if they both have a nested policy expression and the 
alternative in the nested policy expression of one is compatible with the 
alternative in the nested policy expression of the other.
“
it follows that nested policy assertions A1 and B1 are not compatible, because 
A2 and B2 are not compatible.

By the following rule from WS Policy:
“
*	Two policies are compatible if an alternative in one is compatible with an 
alternative in the other. If two policies are compatible, their intersection is 
the set of the intersections between all pairs of compatible alternatives, 
choosing one alternative from each policy. If two policies are not compatible, 
their intersection has no policy alternatives.
“
it follows that policy A and B are not compatible since there is no alternative 
in A compatible with an alternative in B.  

Thus A Intersect B has no alternatives:

----------

3  Intersection of C with B:

Normalized Policy Expression C:
<wsp:Policy>
  <wsp:ExactlyOne>
    <wsp:All> <!— Alternative C1 -->
      <wsam:Addressing>
        <wsp:Policy>
          <wsp:ExactlyOne>
            <wsp:All>  <!— inner Alternative C2 -->
              <wsam:AnonymousResponses/>
            </wsp:All> 
            <wsp:All/> <!— inner Alternative C3 -->
          </wsp:ExactlyOne>
        </wsp:Policy>
      </wsam:Addressing?
    </wsp:All> 
  </wsp:ExactlyOne>
</wsp:Policy>

Normalized Policy Expression B:
<wsp:Policy>
  <wsp:ExactlyOne>
    <wsp:All> <!—  Alternative B1 -->
      <wsam:Addressing>
        <wsp:Policy>
          <wsp:ExactlyOne>
            <wsp:All> <!— inner Alternative B2 -->
              <wsam:AnonymousResponses/>
            </wsp:All> 
          </wsp:ExactlyOne>
        </wsp:Policy>
      </wsam:Addressing?
    </wsp:All> 
  </wsp:ExactlyOne>
</wsp:Policy>

Assertions C1 and B1 each contain a nested policy expression.

The inner nested alternatives of C are (C2):
            <wsp:All> 
              <wsam:AnonymousResponses/>
            </wsp:All> 
and (C3)
            <wsp:All/> <!— inner Alternative C3 -->
while, the inner nested alternative of B is (B2):
            <wsp:All> 
              <wsam:AnonymousResponses/>
            </wsp:All> 

C2 and B2 are compatible since each is an identical assertion.

By application of the other rules the intersection of C and B is as follows:
<wsp:Policy>
  <wsp:ExactlyOne>
    <wsp:All> 
      <wsam:Addressing>
        <wsp:Policy>
           <wsp:ExactlyOne>
             <wsp:All> 
               <wsam:AnonymousResponses/> <!—intersection of C2 and B2 -->
             </wsp:All> 
           </wsp:ExactlyOne>
        </wsp:Policy>
      </wsam:Addressing?
    </wsp:All> 
  </wsp:ExactlyOne>
</wsp:Policy>

which happens to be equivalent to policy expression B.

------

4 Use of Ignorable attribute

Lets try another policy Expression D, which uses the Ignorable Attribute:
<wsp:Policy> 
    <wsam:Addressing> 
        <wsp:Policy> 
            <wsam:AnonymousResponses wsp:Ignorable="true"/> 
        </wsp:Policy> 
    </wsam:Addressing> 
</wsp:Policy>
 
Normalized Policy Expression D:
<wsp:Policy>
  <wsp:ExactlyOne>
    <wsp:All> <!—  Alternative D1 -->
      <wsam:Addressing>
        <wsp:Policy>
          <wsp:ExactlyOne>
            <wsp:All> <!— inner Alternative D2 -->
              <wsam:AnonymousResponses wsp:Ignorable=”true”/>
            </wsp:All> 
          </wsp:ExactlyOne>
        </wsp:Policy>
      </wsam:Addressing?
    </wsp:All> 
  </wsp:ExactlyOne>
</wsp:Policy>

By application of the following rule for Lax Intersection Algorithm from WS 
Policy:
“
 - If the mode is lax, two policy alternatives A and B are compatible:
    *	if each assertion in A that is not an ignorable policy assertion is 
compatible with an assertion in B, and
    *	if each assertion in B that is not an ignorable policy assertion is 
compatible with an assertion in A.

If two alternatives are compatible, their intersection is an alternative 
containing all of the assertions in both alternatives.
“
A2 and D2 are Lax compatible, and the Lax intersection of A2 with D2 is:
            <wsp:All> <!— A2 intersectLax D2 -->
              <wsam:AnonymousResponses wsp:Ignorable=”true”/>
            </wsp:All> 
 
Note that if the wsdl policy supports expression D, and the client supports 
expression A, their lax intersection (A intersectLax D) is:

<wsp:Policy>
  <wsp:ExactlyOne>
    <wsp:All> 
      <wsam:Addressing>
        <wsp:Policy>
           <wsp:ExactlyOne>
            <wsp:All> <!— D2 intersectLax A2 -->
              <wsam:AnonymousResponses wsp:Ignorable=”true”/>
            </wsp:All> 
           </wsp:ExactlyOne>
        </wsp:Policy>
      </wsam:Addressing?
    </wsp:All> 
  </wsp:ExactlyOne>
</wsp:Policy>

Note that if the wsdl policy supports expression D, and the client supports 
expression A,their lax intersection is equivalent to expression D. 

I think this is a better alternative than having the WSDL support B and the 
client supporting C.  In the end the client will have an intersected policy 
which includes the ignorable assertion for anonymousResponses.