Title: Example based on WSA experience for Section 8
Target: Guidelines Section 8

Description: The current section 8 is supposed to include guidance for policy assertion authors but it currently contains an example for policy expression authors.

Based on the experiences between the WSA group and the WS-Policy group, I propose that we add this as the "example" in section 8 and offer this as a strawman.

------------------------------------------------------------------------------
<add>

During the course of the specification editing, review and testing, the working group collected the previous set of Best Practices.

The Guidance included in this document addresses both the design and the use of policy assertions.

As such this section contains two parts: the first a scenario representing a new audience of assertion designers and the process of creating a set of assertions ( drawn from the experiences of the addressing, security and reliable messaging WG members who also participated in the policy WG) and the second a scenario for a hypothetical company that is attempting to utilize the assertions defined by the WS-Security, WS-Addressing and WS-Reliable Messaging working groups.

8.1 Designing Assertions
The WS-Addressing group had several behaviors that they wanted to express using the WS-Policy Framework.  They wanted to indicate at a general level that an entity implemented the WS-Addressing specification. Within the specification it was possible for implementers to chose whether they supported anonymous responses or non-anonymous responses in the context of a message exchange patterns.

The authors chose to represent the behaviors through defining 3 assertions for  WS-Addressing; one parent assertion and two nested assertions.  The parent assertion indicates that both forms of responses are supported.  If the parent assertion is qualified with a nested assertion, non-anonymous then it indicates that only that behavior is supported.
Parent Assertion
The wsam:Addressing policy assertion is a nested policy container assertion. The meaning of this assertion, when present in a policy alternative, is that WS-Addressing is required to communicate with the subject. The wsam:Addressing assertion indicates that there are no restrictions on the use of WS-Addressing unless otherwise qualified by assertions in its nested policy expression. In order to indicate that the subject supports WS-Addressing but does not require its use, an additional policy alternative should be provided which does not contain this assertion. This may be done in WS-Policy compact form by adding the attribute wsp:Optional="true" to the wsam:Addressing assertion.

Nested AnonymousResponses Assertion
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 policy assertion nesting ([WS Policy 1.5], section 4.3.2).
The appearance of this element within the wsam:Addressing policy assertion indicates that the endpoint requires request messages to use response endpoint EPRs that contain the anonymous URI ("http://www.w3.org/2005/08/addressing/anonymous") as the value of [address]. In other words, the endpoint requires the use of anonymous responses.
The None URI ("http://www.w3.org/2005/08/addressing/none") may appear as the value of [address] in place of the anonymous URI; this value MUST be accepted.
Nested NonAnonymousResponses Assertion
The wsam:NonAnonymousResponses element MAY be used as a policy assertion nested within the Addressing assertion in accordance with the rules laid down by policy assertion nesting ([WS Policy 1.5], section 4.3.2). The wsam:NonAnonymousResponses policy assertion MUST NOT be used in the same policy alternative as the wsam:AnonymousResponses policy assertion.
The appearance of this element within the wsam:Addressing assertion indicates that the endpoint expresses requires request messages to use response endpoint EPRs that contain something other than the anonymous URI as the value of [address]. In other words, the endpoint requires the use of non-anonymous responses. This assertion is deliberately vague; its presence indicates that some non-anonymous addresses will be accepted but doesn't constrain what such an address might look like. A receiver can still reject a request that contains an address that it doesn't understand or that requires a binding it doesn't support.
The None URI ("http://www.w3.org/2005/08/addressing/none") may appear as the value of [address] in place of a non-anonymous address; this value MUST be accepted.

Example 3-1. Subject supports WS-Addressing
<wsp:Policy>
    <wsam:Addressing wsp:Optional="true">
        <wsp:Policy/>
    </wsam:Addressing>
</wsp:Policy>
Example 3-2. Subject requires WS-Addressing
<wsp:Policy>
    <wsam:Addressing>
        <wsp:Policy/>
    </wsam:Addressing>
</wsp:Policy>
Example 3-3. Subject requires WS-Addressing and requires the use of non-anonymous response EPRs
<wsp:Policy>
    <wsam:Addressing>
        <wsp:Policy>
            <wsam:NonAnonymousResponses/>
        </wsp:Policy>
    </wsam:Addressing>
</wsp:Policy>