Re: proposed f/b on WS-A Metadata draft from task force

All,

Note that Umit's and my posts on this subject are identical. We simply had 
a "faylure to cammunicate" as to who would
send the proposal to the WG. Note that I fixed a couple of typos in mine 
that I found independently of our agreement
to publish to the WG.

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

public-ws-policy-request@w3.org wrote on 02/20/2007 07:25:44 PM:

> 
> The task force assigned to review the WS-Addressing Metadata draft 
> [1] proposes the following 
> feedback be submitted to the WS-Addressing WG. The TF participants 
> included Asir, Umit, Chris, Dan, Maryann, 
> Tom Rutt. 
> 
> [1] http://www.w3.org/TR/2007/WD-ws-addr-metadata-20070202 
> 
> 
---------------------------------------------------------------------------- 

> 
> WS-Addressing Metadata 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. 
> 
> <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> 
> 
> B) The problematic semantics expressed above makes the utilization 
> of the intersection algorithm provided by WS-Policy 
> framework practically useless. Given that the nested assertions 
> express "support"s semantics, 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. 
> 
> Specifically, 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, 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: 
> 
> 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.? 

> 
> [1] 
> 
> 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