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

Tom Rutt wrote:
>
> Gilbert Pilz wrote:
I now see that it is easier to define nonAnonymosResponses as NOT using 
wsa:Anonymous URI.for responses.  I have posted a new email showing two 
example policy expressions, for
what I call alternative a) (which agrees with Gil's interpretation) and 
alternative b) which treats MakeConnection as being outside of 
wsa:nonAnonymousResponses behaviour.  The biggest problem with b) is 
defining "connectable URI for responses", in a transport independendent 
manner.

My newer email is posted as: 
http://lists.w3.org/Archives/Public/public-ws-addressing/2007Feb/0017.html

>> 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 15:29:42 UTC