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.