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.