Re: Proposal for WS-Policy assertions

This looks pretty good.  In particular (unless I missed something) it
ought to lay CR33 well and truly to rest.  A couple of questions:

    * Do we mean "replies" or "responses"?  That is, does the policy
      apply to [reply endpoint] or to it and [fault endpoint]
      collectively.  If the latter, is there any need to slice more
      finely ("This is OK for replies but not for faults")?  I don't see
      an obvious use case, but it seems worth asking.  If it applies to
      both, I would recommend changing the name to reflect that.
    * I'm not greatly bothered if we don't define a means of saying "I
      can send replies via email" and such as long as there's clearly
      room to do so.  I can see at least two with the proposed scheme:
         1. Allow an {any} extension point for children of
            NonAnonymousReplies, so you could say something like
            <wsaw:NonAnonymousReplies> ... something that means "email
            spoken here" ... </wsaw:NonAnonymousReplies>.  The
            wsfoo:clause mentioned below might slot in here, too.
         2. Follow the example below for wsfoo: and just define a new
            clause for "email spoken here".

Do you (or does anyone else) have a preference or other possibility? 
I'm not sure which I prefer.  The idea behind (1) is to group all the
assertions about non-anon replies together.  A client that was only
interested in anon, for example, could then just look for the anon
marker and know it could safely ignore anything under non-anon, while it
could not safely ignore other assertions that were siblings to
anon/non-anon.


Marc Hadley wrote:
> Gilbert and I took an action to propose some assertions for declaring
> WS-Addr requirements/capabilities in WS-Policy. After a bit of
> discussion we came up with the following three assertions:
>
> (i) <wsaw:AddressingRequired/> - the endpoint requires WS-Addressing,
> optionality can be conveyed using WS-Policy constructs.
>
> (ii) <wsaw:AnonymousReplies/> - the endpoint can send replies using
> WS-A anonymous; the endpoint can't send to anon if not present.
>
> (iii) <wsaw:NonAnonymousReplies/> - the endpoint can send replies
> using other addresses; the endpoint can't send to other addresses if
> not present (unless some other assertion adds a class of supported
> addresses).
>
> Assertion (iii) is deliberately vague, its presence means that a
> non-anon address might work but doesn't constrain what such an address
> might look like - a receiver can still reject an address that it
> doesn't grok or that requires a binding it doesn't support. The WG
> decided against specifying things like available response bindings so
> I think this is in line with that decision.
>
> Here are some examples:
>
> <wsp:Policy>
>   <wsaw:AddressingRequired/>
>   <wsaw:AnonymousReplies/>
> </wsp:Policy>
>
> Means that addressing is required and only anonymous replies are
> supported.
>
> <wsp:Policy>
>   <wsaw:AddressingRequired/>
>   <wsaw:NonAnonymousReplies/>
> </wsp:Policy>
>
> Means that addressing is required and only non-anonymous replies are
> supported.
>
> <wsp:Policy>
>   <wsaw:AddressingRequired/>
>   <wsaw:AnonymousReplies/>
>   <wsaw:NonAnonymousReplies/>
> </wsp:Policy>
>
> Means that addressing is required and both anonymous and non-anonymous
> replies are supported.
>
> <wsp:Policy>
>   <wsaw:AddressingRequired>
> </wsp:Policy>
>
> Wouldn't be too useful for anything other than a one-way message since
> neither anonymous nor non-anonymouse replies are supported.
>
> <wsp:Policy>
>   <wsaw:AddressingRequired/>
>   <wsaw:AnonymousReplies/>
>   <wsfoo:AnonReplies/>
> </wsp:Policy>
>
> Means that addressing is required and that anon replies as defined by
> WS-Addr or WS-Foo are supported.
>
> Marc.
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>