RE: Proposal for WS-Policy assertions

I guess I did, sorry.

-bob

 

________________________________

From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com] 
Sent: Monday, November 13, 2006 1:05 PM
To: Bob Freund; David Hull; Marc Hadley
Cc: public-ws-addressing@w3.org
Subject: 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.