RE: Proposal for WS-Policy assertions

I think you misunderstood me. I'm all in favor of WS-Addressing staying out
of the way of other specifications. I was merely making a point about the
mechanics of nesting WS-Policy assertions.
 
- gp


  _____  

From: Bob Freund [mailto:bob@freunds.com] 
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: 

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.