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

+1

Cheers, Sergey

P.S. This would be a great addition to the primer, as a use case, with the name of the assertions, etc, changed...
  ----- Original Message ----- 
  From: Christopher B Ferris 
  To: Fabian Ritzmann 
  Cc: Fabian.Ritzmann@Sun.COM ; public-ws-policy@w3.org 
  Sent: Friday, February 23, 2007 3:22 PM
  Subject: URGENT: Re: proposed f/b on WS-A Metadata draft from task force



  All, 

  I've only seen a +1 from Fabian. Unless there is any pushback, the chairs will send our response 
  to the WS-A WG at EOB TODAY. 

  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 

  Fabian.Ritzmann@Sun.COM wrote on 02/22/2007 04:54:03 AM:

  > Christopher B Ferris wrote:
  > > I've revised this proposal based on the discussion on the call today. 
  > > Note that Tom has actually come up with
  > > two more alternate approaches, each of which, I believe, would resolve 
  > > our concerns and yet allow the WS-A
  > > Metadata to compose with WS-P and with the WS-RM MakeConnection. I'll 
  > > let him make those proposals to the
  > > WG himself.
  > 
  > Thanks Chris. The revised proposal addresses my concerns and I agree 
  > with it.
  > 
  > Fabian
  > 
  > 
  > > __________________
  > >
  > > 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 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."
  > >
  > > [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 
  >