RE: RE: Proposal for WS-Policy assertions

I concur regarding the higher level assertions.

I'm confused as to how all of this relates to the WSDL Binding spec. All of this is in terms of policy assertions alone, but how would this look in the spec itself? These would have to be defined as WSDL markers and then called out as "or an assertion" correct?

Why are we defining wsaw:AddressingRequired and not using the already existing wsaw:UsingAddressing? What's the difference?

Are we proposing to cut wsaw:Anonymous and wsaw:UsingAddressing? Please don't cut markers/assertions that are in use and retain the same namespace.

I don't think this combination makes sense:
<wsp:Policy>
  <wsaw:AddressingRequired/> <!--or <wsaw:UsingAddressing/> -->
  <wsaw:AnonymousReplies/>
  <wsaw:NonAnonymousReplies/>
</wsp:Policy>

I think that's what this means, essentially I don't care:
<wsp:Policy>
  <wsaw:AddressingRequired/> <!--or <wsaw:UsingAddressing/> -->
</wsp:Policy>

The other assertions qualify the first, otherwise it's kind of a meaningless assertion as it never mean anything unless used with the others.


From: public-ws-addressing-request@w3.org [mailto:public-ws-addressing-request@w3.org] On Behalf Of Bob Freund
Sent: Friday, November 10, 2006 3:44 PM
To: Gilbert Pilz; David Hull; Marc Hadley
Cc: public-ws-addressing@w3.org
Subject: RE: Proposal for WS-Policy assertions

Why would not this wg be concerned about other higher order specifications as long as we do not get in the way?
I think that the vote last Monday supports this contention.
I would personally favor proposals that just spoke about what ws-addressing features were supported or not. Other folks can do what pleases them,
Thanks
-bob

________________________________
From: public-ws-addressing-request@w3.org [mailto:public-ws-addressing-request@w3.org] On Behalf Of Gilbert Pilz
Sent: Thursday, November 09, 2006 12:44 PM
To: David Hull; Marc Hadley
Cc: public-ws-addressing@w3.org
Subject: RE: Proposal for WS-Policy assertions

W/regards to extending NonAnonymousReplies I think we need to be careful. I'm concerned about how the extensions would play out in nested WS-Policy assertions. I welcome anyone who knows more about nested policy assertions than I do (fairly low bar here) to comment.

- gp

________________________________
From: public-ws-addressing-request@w3.org [mailto:public-ws-addressing-request@w3.org] On Behalf Of David Hull
Sent: Wednesday, November 08, 2006 8:37 PM
To: Marc Hadley
Cc: public-ws-addressing@w3.org List
Subject: 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:

    *   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.
    *   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.