Re: Policy assertions for CR33

My concern here is that either "back channel" is just an alias for the
existing anon, in which case we should just say "anonymous", or it has
some further meaning beyond that, in which case we are re-opening a
fairly squirmy can of worms.

It seems safest to stick with syntax and leave it to other text to
define the semantics.  For example, we can assert that RM's special form
is allowed or prohibited, but let RM say exactly what that means.

Here is a sketch along those lines:  Define a wsaw:AddressConstraint
element with the following attributes:

    * propertyName=QName: the name of the property (i.e., SOAP header
      usually) that the assertion applies to
    * constraintType="allowed|prohibited", default = "allowed"
    * exactly one of the following
          o address=anyURI: The assertion applies to this particular
            address URI
          o scheme=string: The assertion applies to any URI with this
            scheme (e.g. "http" or "mailto")
          o regexp=string: The assertion applies to any URI matching
            this regexp (pick a notation, any notation ...).  Support
            for this form might be OPTIONAL.

These can then be combined via your favorite policy language.  For
example (keeping in mind that I'm a complete novice at WS-Policy,
particularly as to whether all is prohibited that is not permitted, or
vice versa)

    <ExactlyOne><!-- Anon permitted, everything else prohibited.  -->
      <wsaw:AddressConstraint propertyName="wsa:ReplyTo" address="http://.../anonymous"/>
    </ExactlyOne>

    <All> <!-- Anon prohibited, email allowed -->
      <wsaw:AddressConstraint propertyName="wsa:ReplyTo" constraintType="prohibited" address="http://.../anonymous"/>
      <wsaw:AddressConstraint propertyName="wsa:ReplyTo" scheme="mailto"/>
    </All>

    <All> <!-- Anon permitted; we also allow funky RM stuff -->
      <wsaw:AddressConstraint propertyName="wsa:ReplyTo" address="http://.../anonymous"/>
      <wsaw:AddressConstraint propertyName="wsa:ReplyTo" regexp="http:// /RMAnon.*"/>
    </All> 
      

Since we define "response endpoint" and it's an important case, there
should be a shortcut defined:

     <wsaw:responseConstraint .../>

which expands to the same assertion about wsa:ReplyTo and wsa:FaultTo. 
Finally, we can keep the existing markup, but define it clearly in terms
of the assertions above (taking care not to depend on any particular
policy framework).  I'm quite sure these can be improved in appearance,
but I think the basic idea of leveraging policy frameworks where
possible is sound.

This proposal would apply to option A6 on our list.


Francisco Curbera wrote:
>
> 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