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

I don't agree. I think it comes down to how we define
wsam:NonAnonymousResponses. If we define it to mean "anything other than
wsa:Anonymous" than it seems to me that a message with a
wsa:ReplyTo/wsa:Address = {some instance of the WS-MC anon URI} meets
behavior required by the presence of wsam:NonAnonymousResponses.

The point is that, as far as WS-Addr policies are concerned, wsmc:Anon is
not a subset of or in any way related to wsa:Anon. It seems
counter-intuitive because we "know" that they have certain message
processing characteristics in common, but I think it makes things cleaner if
we define them to be complete separate.

- gp


> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of 
> Anish Karmarkar
> Sent: Monday, February 26, 2007 9:31 AM
> To: Christopher B Ferris
> Cc: bob@freunds.com; public-ws-addressing@w3.org; 
> public-ws-policy@w3.org
> Subject: Re: Last Call Working Draft Transition: Web 
> ServicesAddressing 1.0 - Metadata
> 
> 
> It seems to me that the first recommended approach does not 
> solve the problem that we were trying to solve: allow ws-addr 
> policy to be composable with WSRM and MC spec. The 1st 
> approach does not allow one one to say: ws-addr anon reply-to 
> is supported and no claims about other reply-to addresses.
> 
> It seems like the 2nd approach is more in line with our requirements.
> 
> Comments?
> 
> -Anish
> -- 
> 
> Christopher B Ferris wrote:
> > 
> > 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
> > 
> >  
> > 
> >  
> > 
> >  
> > 
> >  
> > 
> >  
> 
> 

Received on Monday, 26 February 2007 18:09:42 UTC