First cut policy write up

Here's a first cut at the write up for the 11/27 consensus on CR33. My 
apologies if I have mis-phrased anything. The aim is to get to a point where 
we can discuss the actual wording of the proposal rather than the models and 
concepts . . .

----------

[ rephrase first sentence of section 3 ]

[ strike sections 3.1.2 and 3.2 ]

3.2 WS-Policy Assertions

The other mechanism for indicating that a binding or endpoint [ note: open
issue on policy attachment options ] conforms to the WS-Addressing
specification is through the use of the Web Services Policy - Framework
[WS-Policy] and Web Services Policy - Attachment [WS-PolicyAttachment]
specifications. [ insert appropriate references ]. This specification defines
the following three policy assertions:

3.2.1 UsingAddressing Assertion

In addition to the use described in section 3.1, the wsaw:UsingAddressing
element MAY also be used as a policy assertion. The wsaw:UsingAddressing 
policy assertion is semantically equivalent to the wsaw:UsingAddressing WSDL 
extension. Note that the semantics indicated by the use of 
wsdl:required="true" in the WSDL extension (i.e. the fact that Message 
Addressing Properties are required for all request messages) are not available 
to the wsaw:UsingAddressing policy assertion. The absence of the 
wsaw:UsingAddressing policy assertion within a policy alternative does *not* 
indicate that addressing is not supported; it simply indicates the lack of any 
affirmation of support for WS-Addressing.

3.2.1 AnonymousResponses Assertion

This element MAY be used as a policy assertion. 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 wsaw: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.

3.2.2 NonAnonymousResponses Assertion

This element MAY be used as a policy assertion. The appearance of this element 
within a policy alternative indicates that the endpoint will accept request 
messages with response endpoint EPRs that contain something other than the 
anonymous URI as the value of [address]. This assertion is deliberately vague; 
it's presence indicates that a non-anonymous addresses might 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. As with the other assertions, the 
absence of the wsaw:NonAnonymousResponses policy assertion within a policy 
alternative does *not* indicate that the endpoint will not accept request 
messages with response endpoint EPRs that contain something other than the 
anonymous URI address.

3.2.3 Policy Examples

The above policy assertions are designed to be used either independently or in
conjunction with one another. The following examples illustrate some possible
combinations:

<wsp:Policy>
  <wsaw:UsingAddressing>
</wsp:Policy>

This policy indicates that the subject supports the use of WS-Addressing. If a
fault is generated as a result of sending a request message to an endpoint
with this effective policy, that fault will not be due to the simple fact that
the request message includes WS-Addressing headers. Note that nothing is said
about either supporting or not supporting the use of anonymous or
non-anonymous URIs.

<wsp:Policy>
  <wsaw:AnonymousResponses>
</wsp:Policy>

This policy indicates that the subject supports the use of WS-Addressing and,
in particular, will accept request messages with response endpoint EPRs that
contain the anonymous URI. If a fault is generated as a result of sending a
request message to an endpoint with this effective policy, that fault will not
be due to the fact that the request message includes WS-Addressing headers nor
will it be due to the fact that the response endpoint EPRs contain the
anonymous URI as an address. Note that nothing is said about either supporting
or not supporting the use of non-anonymous URIs.

<wsp:Policy>
  <wsaw:UsingAddressing>
  <wsaw:AnonymousResponses>
</wsp:Policy>

The above policy is semantically equivalent to the previous example. Note that
this example could be the result of combining two separate policies (e.g. one
attached at a wsdl:binding and the other at a wsdl20:endpoint (or
wsdl11:port)) into a single effective policy.

<wsp:Policy>
  <wsaw:NonAnonymousResponses>
</wsp:Policy>

<wsp:Policy>
  <wsaw:UsingAddressing>
  <wsaw:NonAnonymousResponses>
</wsp:Policy>

The above two policies are identical ways of expressing the fact that the
subject supports the use of WS-Addressing and, in particular, will accept
request messages with response endpoint EPRs that contain URIs other than the
anonymous URI. If a fault is generated as a result of sending a request
message to an endpoint with either of these policies, that fault will not be
due to the fact that the request message includes WS-Addressing headers nor
will it be due to the mere fact that the response endpoint EPRs contain a
non-anonymous URI as an address. Note that nothing is said about either
supporting or not supporting the use of the anonymous URI.

-------------

- gp