WS-A Action Item: proposal for use of policy

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. 

 
=== 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.
 
Example:
If the client does not require explicit support for anonymous responses, but does require WS-Addressing, and uses a policy assertion of:
 
<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 the policy:
<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:
 
<wsp:Policy>
    <wsam:Addressing>
        <wsp:Policy>
            <wsam:AnonymousResponses wsp:Optional="true"/>
        </wsp:Policy>
    </wsam:Addressing>
</wsp:Policy>
 
which will produce a non-empty intersection both with policies that contain explicit support for anonymous responses, and those without explicit support - the desired result.
 
====
 
To be honest, I haven't followed Policy closely enough to be absolutely certain that the intersection in the first case above will be empty, but I think it will - could one of our Policy-skilled people confirm one way or the other, please?
 
Does this language do a better job of expressing how we intend our policy assertions to be used? Note that I am putting the onus on the client searching for compatible policy to use Optional, rather than having the onus on the server to express it - this makes a lot more sense to me - the server/service states whether it provides explicit / guaranteed support for the feature, and the client goes looking for endpoints with explicit support (if explicit support is required), or with/without explicit support if it is not required (using Optional to express the "don't care aspect"). 
 
(BTW: I don't imagine clients will be wanting to find a server/service with a definite lack of explicit support, so the first client policy above might be one we advise against using - do you agree?)
 
Although this does express a view on how to use WS:Policy, something which we sought to avoid, I don't believe we can avoid it in this case.
 
Tony Rogers
CA, Inc
Senior Architect, Development
tony.rogers@ca.com