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

Gilbert Pilz wrote:
> 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.
>   
we do not need to do this.  Non anonymous can imply requirement for 
addresssable reply to address with a connection to that replyTo address.

We can always add another alternative using another response mechanism 
other than non anonymous or wsa:addressing.

Tom Rutt
> 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
>>>
>>>  
>>>
>>>  
>>>
>>>  
>>>
>>>  
>>>
>>>  
>>>       
>>     


-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Tuesday, 27 February 2007 01:21:22 UTC