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

+1

 

-Charlton.

 

________________________________

From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Christopher B
Ferris
Sent: 23 February 2007 07:23
To: Fabian Ritzmann
Cc: Fabian.Ritzmann@Sun.COM; public-ws-policy@w3.org
Subject: URGENT: Re: proposed f/b on WS-A Metadata draft from task force
Importance: High

 


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 
>