Re: Proposal for WS-Policy assertions

Marc

Just to clarify, can wsaw:AnonymousReplies and/or wsaw:NonAnonymousReplies 
policy assertions exist *without* wsaw:AddressingRequired?

- If 'yes', then in order to simply say 'wsaddressing supported but not 
required', you would need wsp:Optional on the 3 wsaw assertions (i.e. 8 
different options when in normal form - more when you add wsfoo).  Also, I 
guess that the semantics of wsfoo:AnonSupported will need to be defined 
(by wsfoo) as being valid without any of the wsaw policy assertions 
(because, for example, the addition of wsp:Optional on 
wsaw:AnonymousReplies will potentially lead to policy assertions 
containing wsfoo:anonSupported without wsaw:AnonymousReplies)?

- If 'no', then I think we need some kind of nesting here: i.e. 
AnonymousReplies and NonAnonymousReplies are nested assertions of 
AddressingRequired.  Without nesting, we are likely to get invalid policy 
configurations (consider adding wsp:Optional to AddressingRequired).  The 
problem with nesting (as you have already stated in a previous email) is 
the issue of x-domain nested assertions.  Perhaps we could nest just the 
wsaw policy assertions and assume that wsfoo assertions will remain 
un-nested?

Thanks
Katy





Marc Hadley <Marc.Hadley@Sun.COM> 
Sent by: public-ws-addressing-request@w3.org
13/11/2006 14:53

To
Marc Goodner <mgoodner@microsoft.com>
cc
Bob Freund <bob@freunds.com>, Gilbert Pilz <Gilbert.Pilz@bea.com>, David 
Hull <dmh@tibco.com>, "public-ws-addressing@w3.org" 
<public-ws-addressing@w3.org>
Subject
Re: Proposal for WS-Policy assertions






On Nov 10, 2006, at 8:47 PM, Marc Goodner wrote:
> Why are we defining wsaw:AddressingRequired and not using the 
> already existing wsaw:UsingAddressing? What?s the difference?
>
>
UsingAddressing in the absence of Anonymous implies support for any 
address (anon or non-anon). AddressingRequired without one of the 
other assertions only implies support for the none address.
>
>
> 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/>
>
>   <wsaw:AnonymousReplies/>
>
>   <wsaw:NonAnonymousReplies/>
>
> </wsp:Policy>
>
>
Hopefully the previous comment explains why this makes sense. It is 
equivalent to the UsingAddressing WSDL extension when Anonymous isn't 
also used.

Marc.

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

---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.