W3C home > Mailing lists > Public > public-ws-addressing@w3.org > January 2007

RE: New draft of Metadata document - was RE: 2007-01-15 Teleconference canceled due to low attendance <EOM>

From: Rogers, Tony <Tony.Rogers@ca.com>
Date: Mon, 15 Jan 2007 18:58:52 +1100
Message-ID: <BEE2BD647C052D4FA59B42F5E2D946B317B794@AUSYMS12.ca.com>
To: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, "Bob Freund" <bob@freunds.com>, "[WS-A]" <public-ws-addressing@w3.org>
Hello Umit
 
you are quite right, the intersection will fail. 
 
If we interpret the client as MUST have anonymous response, and the server as NOT GUARANTEEING anonymous response, it is arguable that it SHOULD fail.
 
That's my interpretation, anyway.
 
If the server wants to state support for both anon and non-anon, it must not provide the empty policy alone; it must provide empty, anon only, non-anon only, and both.
 
Tony Rogers
CA, Inc
Senior Architect, Development
tony.rogers@ca.com

________________________________

From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com]
Sent: Mon 15-Jan-07 17:28
To: Rogers, Tony; Bob Freund; [WS-A]
Subject: RE: New draft of Metadata document - was RE: 2007-01-15 Teleconference canceled due to low attendance <EOM>


There is some discussion in the WS-Policy wg about the semantics of intersection with empty policy alternatives and nesting. This is why the WS-A approach to using nesting is rather important. 
 
I read the document and the following statement is not very clear. Could the wg clarify what is intended: 
 
{Note also that the lack of either of these assertions (AnonymousResponses and NonAnonymousResponses) does not indicate lack of support. So it is suggested that a subject that does not have a strict compatibility requirement that an interacting subject understands or is concerned with these assertions provides an alternative without either assertion. }
 
For example, your example 3.2 (with no statement on support on supported response EPRs) on a service will fail to intersect with a clients policy which would require anonymous responses. Is the statement quoted above trying to recommend use of alternatives that contain nested assertions to indicate explicit support for type of responses (anonymous/non anonymous) in one of the nested alternatives ? If that is the case, Example 3.2 needs to be positioned appropriately. Using example 3.2 alone as a policy expression by a service will not allow the clients that require a specific type of responses to communicate with the service as the intersection algorithm will fail, but that is not clear from the text. Thus, example 3.2 as "no-statement on supported responses" is misleading. 
 
Cheers, 
 
--umit
 
 
              


________________________________

	From: public-ws-addressing-request@w3.org [mailto:public-ws-addressing-request@w3.org] On Behalf Of Rogers, Tony
	Sent: Sunday, Jan 14, 2007 12:56 PM
	To: Bob Freund; [WS-A]
	Subject: New draft of Metadata document - was RE: 2007-01-15 Teleconference canceled due to low attendance <EOM>
	
	
	So everyone has a whole week to study the new Editor's Draft of the Metadata document :-)  You will find it at: http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.html?content-type=text/html;%20charset=utf-8
	 
	The main changes are the complete removal of UsingAddressing and the SOAP module as alternatives for indicating the use of WS-Addressing (yes, I have anticipated the WG slightly, but I can roll this back if it is not agreed - want you to see what it looks like without those) - the only mechanism supported for indicating/requiring the use of WS-Addressing is the policy assertion.
	 
	Please e-mail the list with any omissions or mistakes. 
	 
	
	Tony Rogers
	CA, Inc
	Senior Architect, Development
	tony.rogers@ca.com

________________________________

	From: public-ws-addressing-request@w3.org on behalf of Bob Freund
	Sent: Mon 15-Jan-07 6:51
	To: [WS-A]
	Subject: 2007-01-15 Teleconference canceled due to low attendance <EOM>
	
	

	 
Received on Monday, 15 January 2007 07:59:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:15 GMT