Policy assertions for CR33

Anish and I agreed to formulate a proposal for a policy assertion 
replacement to the wsaw:Anonymous marker. I think this matches option A6 
in the latest mail from Bob listing the options. 

There are two options proposed below, and we suggest we accept Option 1 
because it is simpler to use and harder to misconfigure. They are 
otherwise similar in their approach. In both cases, there is a 
configuration corresponding to unconstrained WSA behavior, plus two 
additional configurations in which the use of the backchannel is either 
mandated or prohibited for responses. Constrained configurations can only 
be specified for transports where a backchannel is available as an 
alternative. The names of the assertions are of course mildly irrelevant 
here, as long as they convey the correct meaning. One more point: these 
proposals assume no specific implementation of the represented behavior 
(which we think is the right thing to do, as long as it is clear that they 
are implementable). 

Option 1: Introduce three independent policy assertions with the meaning 
"full WSA support", "WSA supported with responses over backchannel only" 
and "WSA supported with responses over new connection only". 
wsaw:UsingAddressing is not necessary in this case and is therefore 
eliminated.

<wsaw:WSASupported/>
<wsaw:WSAResponseOverBackChannel/>
<wsaw:WSAResponseOverNewConnection/>

Option 2: Keep wsaw:UsingAddressing and add two policy assertions that 
qualify WSA support wrt the use of the backchannel:

<wsaw:ResponsesOverBackchannelOnly/>
<wsaw:ResponsesOverNewConnectionOnly/>

If only wsaw:UsingAddressing is used, then unrestricted WSA support is 
assumed. If in addition to wsaw:UsingAddressing one of the assertions 
above is used, then WSA behavior is accordingly limited for response 
messages. In this case, using any of the Response* policy assertions 
requires using the wsaw:UsingPolicy marker as well.


Paco and Anish