RE: FW: Last Call Working Draft Transition: Web ServicesAddressing 1.0 - Metadata

Paco,
 
I am responding to your option 1, where you say "retain the current
design as it works". 
 
I observe that the WS-Policy related design did not take 5 months of
design. That is relatively new as some of us watch this space.
Especially the inclusion of wsp:ignorable was somewhat of a surprise, at
least to me. 
 
Please put yourself into your readers shoes. They will not know the
details of WS-RX issue.  Some of us, who used to be part of this wg were
even baffled by the writeup. Many thanks to Tom who was part of the task
force, we could rewind and reinterpret the semantics with WS-RX/WS-A hat
on and decipher why the spec is written the way it may be. The industry
at large outside this group would not be able to interpret these subtle
semantics and to make use of it. (Some people believe perhaps that is
the critical majority, but at least I am not one of them ;-)). 
 
As a reader of the metadata document, I could not comprehend the
intention of the specification just by reading the specification alone.
Not everyone will have a Tom with them ;-).  Please do not retain the
document as it is. It is not really doing a service to WS-A/WS-RX in its
current form, or to the community at large who want to use
WS-Policy/WS-A/WS-RX. 
 
There may be other ways to solve the WS-RX and WS-A integration rather
than, at least for some of us, the misuse of the WS-Policy framework. It
may be possible to find a solution collectively. 
 
 
--umit
 


________________________________

	From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Francisco
Curbera
	Sent: Monday, Feb 26, 2007 11:11 AM
	To: Bob Freund
	Cc: [WS-A]; public-ws-addressing-request@w3.org
	Subject: Re: FW: Last Call Working Draft Transition: Web
ServicesAddressing 1.0 - Metadata
	
	

	Unfortunately I will not be able to make the call today, my
regrets. Here are my thoughts about the policy WG's comments. 
	
	A. It is not clear what is 'incompatible' about the two
alternatives that appear in the normal form provided; at most, they are
potentially overlapping in the behavior they describe. Intersection will
work fine and catch both clients with and w/o the wsa:AnonymousResponses
qualifier. Again, it is not clear what is broken here. 
	
	B. It is true that restricting behavior is not properly
supported, but that is what we decided after months of struggling with
the RM anon issue. Standards are made of compromises. Not sure why the
policy wg thinks it 'likely' that people will assume semantics
incompatible with ones we spec out. 
	
	C (first occurrence). WSA Metadata does not provide a way to say
that ONLY a certain type of responses are allowed. This is by design.
The reasoning that follows is thus based on an incorrect reading of the
assertion semantics. I think we have discussed at length option 1 and
leaving the required behavior model is what got us our of the rat hole;
as for 2, I believe we have discussed and rejected it in the past (what
options haven't we considered already?) but the reasons may have been
people's desire to leverage intersection for the anonymous assertions as
well.   
	
	With respect to A, B and C(1), I believe the net is this: we
have decided to go for an assertion structure and semantics that only
supports positive statements about the types of responses supported. We
don't need to go back and review the 5 months we've spent to reach this
point. In the considerations provided by the policy wg there seems to be
a level of uneasiness with and/or misunderstanding of those semantics,
not a specific proof that anything is broken. So I think we have three
options: 1. maintain the current design (since it works), 2. go back to
a restrictive wsa:anonymous design (forget about RM), or 3. just stay
away from the business of indicating response types (forget about
anonymous). Based on all the work we've done I would say we go for #1,
*maybe* considering once more the possibility of using nested elements
instead of nested policy. 
	  
	C (second occurrence). The comment seems to miss the point that
other specifications might define assertions to be nested within the
wsa:Addressing assertion, so multiple namespaces are possible. OTOH,
nothing in the WS-Policy specification states that the use of the
ignorable flag is tied to lack of understanding of the assertion
semantics by clients. Operationally its value is quite clear: it
supports lax intersection. This comment makes me wonder if we should in
fact use the ignorable flag :-) 
	
	D. I agree we should clarify this. 
	
	E. I think the document is quite clear about what are the
allowable attachment points. Do we need to exhaustively list all not
supported attachment points? 
	
	Paco 
	
	
	
	
"Bob Freund" <bob@freunds.com> 
Sent by: public-ws-addressing-request@w3.org 

02/23/2007 03:53 PM 

To
"[WS-A]" <public-ws-addressing@w3.org> 
cc
Subject
FW: Last Call Working Draft Transition: Web ServicesAddressing 1.0 -
Metadata

	




	  
	
	
________________________________

	From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
	Sent: Fri 2/23/2007 11:26 AM
	To: Bob Freund; www-ws-desc@w3.org
	Cc: public-ws-policy@w3.org
	Subject: Last Call Working Draft Transition: Web
ServicesAddressing 1.0 - Metadata
	
	
	On behalf of the WS-Policy WG, here is our feedback on the
WS-Addressing Metadata specification. 
	
	The document specifies a wsam:Addressing assertion that has two
nested assertions 
	wsam:AnonymousResponses and wsam:NonAnonymousResponses
assertions. 
	
	Although the use of the wsam:Addressing assertion indicates a
requirement, the nested assertions do not 
	express requirements, thus dependent behaviors.  The nested
assertions appear to express support of a capability. 
	
	In our opinion, this duality poses several problems related to
both understanding the intent of the assertion and 
	to utilization of the WS-Policy 1.5 Framework for purposes of
intersection. These problems are noted below, 
	followed by our recommendations to address the problems we
highlight. 
	
	(A) The presence of either of the two nested assertions does not
indicate a required behavior. 
	Further, per the statements in Sections 3.1.2 and 3.1.3, their
absence does not indicate lack of support either: 
	     "The absence of the XX policy assertion within a policy
alternative does not indicate that the 
	     endpoint will not accept request messages with response
endpoint EPRs that contain the anonymous 
	     URI as an address; it simply indicates the lack of any
affirmation of support for XX URIs." 
	
	Thus, we believe that neither the presence nor absence of
wsam:AnonymousResponses or wsam:NonAnonymousResponses 
	as nested policy assetions is meaningful. 
	
	Without making the semantic change to the assertions, the
expression exemplified below is meaningless. 
	
	<wsam:Addressing> 
	<wsp:Policy> 
	 <wsam:AnonymousResponses wsp:optional="true"/> 
	</wsp:Policy> 
	</wsam:Addressing> 
	
	The equivalent normalized expression implies conflicting
semantics. The normalized policy expression 
	(see below) gives no indication which alternative can be used. 
	
	The first alternative indicates support for anonymous responses,
but does not indicate whether a client that does 
	not support that behavior should not use this alternative
(because absence of the wsam:NonAnonymousResponses 
	nested assertion explicitly does NOT make any statement as to
whether or not that feature is supported). Similarly, 
	the second alternative makes no statement what-so-ever as
regards the support (or lack there-of) of anon or non-anon 
	responses. 
	
	<wsp:ExactlyOne> 
	<wsp:All> 
	 <wsam:Addressing> 
	   <wsp:Policy> 
	     <wsp:ExactlyOne> 
	       <wsp:All> 
	         <wsam:AnonymousResponses/> 
	       </wsp:All> 
	     </wsp:ExactlyOne> 
	   </wsp:Policy> 
	 </wsam:Addressing> 
	</wsp:All> 
	<wsp:All> 
	 <wsam:Addressing> 
	   <wsp:Policy/> 
	 </wsam:Addressing> 
	</wsp:All> 
	</wsp:ExactlyOne> 
	
	The problematic semantics expressed above makes the utilization
of the intersection algorithm provided by WS-Policy 
	framework practically useless. 
	
	(B) Given that the nested assertions express "support"s
semantics, and given that their omission says nothing about 
	lack of support, it is not possible for an endpoint to advertise
that it explicitly DOES NOT support one or the other. However, 
	it is likely that some policy authors might be lead to believe
that by simply including only one of the nested assertions, 
	that a policy consumer would read that and infer that the other
is not supported, despite the fact that the spec says 
	that it makes no statement. 
	
	Thus, we believe that it is not possible to intersect the
behaviors of a consumer and a provider meaningfully to rely 
	on the intersection algorithm alone to express required
behaviors. 
	
	(C) The advocation in section 3.1.6 of the use of
wsp:Optional='true' to enable intersection of two policy 
	expressions when one side chose to omit making any statement
about its capabilities is itself problematic. 
	Using the WS-Policy 1.5 Framework intersection, the following
two policies would be compatible, despite the 
	fact that the possible intent of the respective authors was
meant to relate that ONLY the expressed nested 
	assertion was supported (see (B)): 
	
	Client: 
	<wsam:Addressing> 
	<wsp:Policy> 
	 <wsam:AnonymousResponses wsp:optional="true"/> 
	</wsp:Policy> 
	</wsam:Addressing> 
	
	Server: 
	<wsam:Addressing> 
	<wsp:Policy> 
	 <wsam:NonAnonymousResponses wsp:optional="true"/> 
	</wsp:Policy> 
	</wsam:Addressing> 
	
	This is because the normalized expressions would each have an
alternative with an empty nested policy 
	and the policy engine applying intersection would report that
there was a compatible policy alternative(s): 
	
	<wsam:Addressing> 
	<wsp:Policy/> 
	<wsam:Addressing> 
	
	Our guidelines document [1] in Section 4.5.1 further clarifies
the appropriate use of wsp:optional attribute to create alternatives 
	to indicate required and supported behaviors. 
	
	Based on our review, we recommend adoption of one of the two
options that follow to resolve (A) and (B) above. In our view, it is 
	important to align the semantics of the nested aqssertions with
the WS-Policy 1.5 Framework processing semantics. 
	
	1. One recommended approach would be to change the semantic of
the nested policy assertions to represent required behavior 
	and use policy operators to convey the precise semantics. 
	
	e.g. 
	
	<wsam:Addressing> <!-- anon responses required, non-anon
prohibited --> 
	<wsp:Policy> 
	 <wsp:ExactlyOne> 
	   <wsp:All> <!-- anon responses required --> 
	     <wsam:AnonymousResponses/> 
	   </wsp:All> 
	 <wsp:ExactlyOne> 
	</wsp:Policy> 
	</wsam:Addressing> 
	
	<wsam:Addressing> 
	<wsp:Policy> 
	 <wsp:ExactlyOne> 
	   <wsp:All> <!-- non-anon responses required, anon prohibited
--> 
	     <wsam:NonanonymousResponses/> 
	   </wsp:All> 
	 </wsp:ExactlyOne> 
	</wsp:Policy> 
	</wsam:Addressing> 
	
	<wsam:Addressing> 
	<wsp:Policy> 
	 <wsp:ExactlyOne> 
	   <wsp:All> <!-- either anon and non-anon responses required-->

	     <wsam:AnonymousResponses/> 
	  </wsp:All> 
	  <wsp:All> 
	     <wsam:NonanonymousResponses/> 
	   <wsp:All> 
	 </wsp:ExactlyOne> 
	</wsp:Policy> 
	</wsam:Addressing> 
	
	Note with this last one, it might be necessary to clarify that
the scope of the assertion applies to a single instance of an MEP, 
	not to all instances of MEPs associated with the endpoint.... to
allow the client to choose for each message exchange the appropriate 
	type of response. 
	
	Section 3.1.2 and 3.1.3 should be updated to convey that nested
assertions indicate dependent behaviors by 
	removing the quoted sections above. 
	
	2. Alternately, we believe that if the intent of the semantic to
be conveyed is indeed purely informational (i.e. that an 
	endpoint "supports" the capability) that a more appropriate
means of expressing this would be to use assertion 
	parameters rather than nested policy: 
	
	e.g. 
	
	<wsam:Addressing> 
	<wsam:AnonymousResponses/> 
	<wsam:NonAnonymousResponses/> 
	</wsam:Addressing> 
	
	Note that with this second approach, the use of assertion
parameters would not effect policy intersection, yet the 
	assertion parameters could be used by the policy consumer as
information that it could use to determine appropriate 
	use of addressing. If formal processing the assertion parameters
is deemed to be necessary, then domain specific 
	intersection processing would need to be designed. For more
information on usage of nested vs. parametric assertions, 
	please see Section 4.4 in our Guidelines document for details. 
	
	(C) We note that the use of wsp:ignorable is not appropriate in
this context. Whether the semantics of the nested policy 
	imply required or "supported", we note that once the assertion
(wsam:Addressing) is understood, that any nested policy 
	or parameters would also be understood by the client (by
definition). Thus, we believe that the WS-Addressing Metadata 
	specification should not be making any recommendations as to the
use of wsp:ignorable in section 3.1.6. 
	
	(D) The WS-Addressing Metadata draft does not specify a policy
subject, but implies one. Instead, the draft specifies 
	attachment points. We recommend making the policy subject
explicit. Please refer to our guideline in Section 4.6 in our 
	Guidelines document, "An assertion description should specify a
policy subject. For instance, if a policy assertion is to 
	be used with WSDL, an assertion description should specify a
WSDL policy subject - such as service, endpoint, 
	operation and message." 
	
	(E) The WS-Addressing Metadata draft should rule out
wsdl:portType and wsdl20:interface as possible attachment points. 
	e.g, 
	"A policy expression containing the Addressing policy assertion
MUST NOT be attached to a wsdl:portType or wsdl20:interface. 
	The Addressing policy assertion specifies a concrete behavior
whereas the wsdl:portType or wsdl20:interface is an abstract construct."

	
	Cheers, 
	
	Christopher Ferris
	STSM, Software Group Standards Strategy
	email: chrisfer@us.ibm.com
	blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
	phone: +1 508 377 9295 
	
	__________________ 
	
	
	
	The W3C WS-Addressing WG has published a Last Call Working Draft
of Web Services Addressing 1.0 - Metadata specification.  The deadline
for comments is 23 February 2007. The document is available at 
	
	 
	
	 http://www.w3.org/TR/2007/WD-ws-addr-metadata-20070202/ 
	
	 
	
	We look forward to receiving any comments your WG has on this
Last Call Working Drafts. Comments on this document are invited and are
to be sent to the public public-ws-addressing-comments@w3.org
<mailto:public-ws-addressing-comments@w3.org>  mailing list.  We are
interested in particular in comments from the Web Services Policy and
Web Services Description Working Group. We are also interested in
comments from OASIS technical committees, in particular the Web Services
Reliable Exchange (WS-RX) TC. 
	
	 
	
	Please note that the document contains substantial changes
compared to the previous version. In particular, the document does no
longer define a WSDL extension element or a WSDL SOAP module. This new
version defines WS-Policy assertions, based on the Web Services Policy
1.5 framework. 
	
	 
	
	If your Working Group is interested in reviewing these drafts,
please let me know, especially if you think you need more than three
weeks after publication for your review. 
	
	 
	
	The decision to move to Last Call was made on January 29, 2007
[1]. 
	
	 
	
	No formal objection has been reported. 
	
	 
	
	No patent disclosure has been reported. 
	
	 
	
	Thanks 
	
	-bob 
	
	 
	
	W3C WS-Addressing WG chair 
	
	 
	
	[1] http://www.w3.org/2007/01/29-ws-addr-minutes.html 
	
	 
	
	 
	
	Bob Freund, Hitachi, Ltd. 
	
	62 Peakham Road, Sudbury, Massachusetts 01776-2914 
	
	Tel: +1-978-440-8415,  Fax: +1-978-443-2168