RE: First cut policy write up

My statement wasn't precise, my apologies. I don't mean nesting the UsingAddressing assertion itself, I mean changing it so it can contain nested policy.

-----Original Message-----
From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com]
Sent: Monday, December 04, 2006 12:41 PM
To: Marc Goodner; David Illsley
Cc: public-ws-addressing@w3.org
Subject: RE: First cut policy write up

Wait, why are we talking about nesting UsingAddressing? I thought that, if
we did get into nesting our policy assertions, UsingAddressing would have to
be the top-level, containing assertion.

- gp

> -----Original Message-----
> From: Marc Goodner [mailto:mgoodner@microsoft.com]
> Sent: Monday, December 04, 2006 12:37 PM
> To: David Illsley; Gilbert Pilz
> Cc: public-ws-addressing@w3.org
> Subject: RE: First cut policy write up
>
> So are you also proposing that UsingAddressing now be only a
> policy assertion? Or is it possible to describe its use as
> both a WSDL marker and as a nested policy assertion?
>
> -----Original Message-----
> From: public-ws-addressing-request@w3.org
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of
> David Illsley
> Sent: Friday, December 01, 2006 5:03 AM
> To: Gilbert Pilz
> Cc: public-ws-addressing@w3.org
> Subject: Re: First cut policy write up
>
>
> I spent a while yesterday going over this proposal with Katy,
> Paco, and our WS-Policy development team and we have a couple
> of concerns.
>
> 1. There is no way to mandate addressing in this proposal
> i.e. In normal form (once the wsp:Optionals etc have been
> expanded) the presence of wsaw:UsingAddressing only indicates
> addressing is supported. We need a way to say addressing is
> required. I don't have a proposal yet to deal with this.
>
> 2. I was a little unclear reading the proposal and then the
> examples if the AnonymousResponses element implies addressing
> is supported.. hence 2a and 2b below
>
> 2a. AnonymousResponses implies addressing supported
>         As noted in elsewhere in the thread,
> AnonymousResponses and UsingAddressing won't intersect which
> doesn't fit with the policy processing model.
>                 e.g. A server which only supports
> AnonymousResponses only includes the AnonymousResponses
> assertion. A client doesn't care and has the UsingAddressing
> assertion.
>                         These assertions clearly don't
> intersect, and requiring any policy subject which supports
> anon and non-anon to include all 3 as wsp:Optional="true"
> will significantly increase the number of alternatives on
> normalisation. It also includes alternatives in which
> addressing is not supported which is not the intent.
>
> 2b. AnonymousResponses does not imply addressing supported -
> UsingAddressing also needed to indicate addressing suppot
>         In this case, to allow a client policy which only has
> the UsingAddressing assertion to intersect with a server
> policy with the AnonymousResponses assertion, the
> AnonymousResponses assertion would have to be
> wsp:Optional="true". If addressing support (UsingAddressing)
> is itself optional then when this is expanded to normal form
> there will be an invalid alternative containing just the
> AnonymousResponses assertion.
>
> The solution (and proposal) we arrived at for 2 is to use
> proper nested policy[1] (not parameterised policy[2] as
> discussed on the Monday call).
> This seems appropriate as the type of responses supported is
> dependant on the fact that addressing is supported. The use
> of nested WS-Policy for this situation is explicitly called
> out in the WS-Policy Primer[3].
>         Extract: "Best practice: represent dependent
> behaviors that apply to the same policy subject using nested
> policy assertions. "
>
> This follows the path of 2b where the UsingAddressing (or a
> replacement given 1 above) is used to indicate addressing
> support and the other assertions clarify. It has the
> advantage that none of the generated alternatives when taken
> to normal form are invalid.
>
> This would look like*:
>  1. Addressing supported, no statement about response EPRs
> supported <wsaw:UsingAddressing>
>         <wsp:Policy />          <!- required by WS-Policy Framework
> Section 4.3.2 -->
> </wsaw:UsingAddressing>
>
> 2. Addressing supported, AnonymousResponses explicitly
> supported <wsaw:UsingAddressing>
>         <wsp:Policy>
>                 <wsaw:AnonymousResponses wsp:Optional="true" />
>         </wsp:Policy>
> </wsaw:UsingAddressing>
>
> 3. Addressing supported, NonAnonymousResponses explicitly
> supported <wsaw:UsingAddressing>
>         <wsp:Policy>
>                 <wsaw:NonAnonymousResponses wsp:Optional="true" />
>         </wsp:Policy>
> </wsaw:UsingAddressing>
>
> 4. Addressing supported, Anonymous and NonAnonymousResponses
> explicitly supported <wsaw:UsingAddressing>
>         <wsp:Policy>
>                 <wsaw:AnonymousResponses wsp:Optional="true" />
>                 <wsaw:NonAnonymousResponses wsp:Optional="true" />
>         </wsp:Policy>
> </wsaw:UsingAddressing>
>
> A client which requires explicit support of anonymous
> responses would then have a policy of:
> <wsaw:UsingAddressing>
>         <wsp:Policy>
>                 <wsaw:AnonymousResponses/>
>         </wsp:Policy>
> </wsaw:UsingAddressing>
>
> which would intersect with 2 and 4.
>
> David
>
> * N.B. There is a discussion to be had about whether the
> above wsaw:AnonymousResponse and wsaw:NonAnonymousResponses
> should be wsp:Ignorable rather than wsp:Optional but
> wsp:Ignorable is new and less well understood so agreement on
> a nested approach seems like a good first step.
>
> [1]
> http://www.w3.org/TR/2006/WD-ws-policy-20061117/#nested_policy
_expression
> [2]
> http://www.w3.org/TR/2006/WD-ws-policy-20061117/#policy_assert
ion_parameter
> [3]
> http://www.w3.org/TR/2006/WD-ws-policy-primer-20061018/#levera
ging-nested-policy
>
> David Illsley
> Web Services Development
> MP211, IBM Hursley Park, SO21 2JN
> +44 (0)1962 815049 (Int. 245049)
> david.illsley@uk.ibm.com
>
>
>
> From:
> "Gilbert Pilz" <Gilbert.Pilz@bea.com>
> To:
> <public-ws-addressing@w3.org>
> Date:
> 11/29/2006 11:20 PM
> Subject:
> First cut policy write up
>
>
> Here's a first cut at the write up for the 11/27 consensus on
> CR33. My apologies if I have mis-phrased anything. The aim is
> to get to a point where we can discuss the actual wording of
> the proposal rather than the models and concepts . . .
>
> ----------
>
> [ rephrase first sentence of section 3 ]
>
> [ strike sections 3.1.2 and 3.2 ]
>
> 3.2 WS-Policy Assertions
>
> The other mechanism for indicating that a binding or endpoint
> [ note: open issue on policy attachment options ] conforms to
> the WS-Addressing specification is through the use of the Web
> Services Policy - Framework [WS-Policy] and Web Services
> Policy - Attachment [WS-PolicyAttachment] specifications. [
> insert appropriate references ]. This specification defines
> the following three policy assertions:
>
> 3.2.1 UsingAddressing Assertion
>
> In addition to the use described in section 3.1, the
> wsaw:UsingAddressing element MAY also be used as a policy
> assertion. The wsaw:UsingAddressing policy assertion is
> semantically equivalent to the wsaw:UsingAddressing WSDL
> extension. Note that the semantics indicated by the use of
> wsdl:required="true" in the WSDL extension (i.e. the fact
> that Message Addressing Properties are required for all
> request messages) are not available to the
> wsaw:UsingAddressing policy assertion. The absence of the
> wsaw:UsingAddressing policy assertion within a policy alternative does
> *not*
> indicate that addressing is not supported; it simply
> indicates the lack of any affirmation of support for WS-Addressing.
>
> 3.2.1 AnonymousResponses Assertion
>
> This element MAY be used as a policy assertion. The
> appearance of this element within a policy alternative
> indicates that the endpoint will accept request messages with
> response endpoint EPRs that contain the anonymous URI
> ("http://www.w3.org/2005/08/addressing/anonymous") as the
> value of [address]. The absence of the
> wsaw:AnonymousResponses 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 anonymous URIs.
>
> 3.2.2 NonAnonymousResponses Assertion
>
> This element MAY be used as a policy assertion. The
> appearance of this element within a policy alternative
> indicates that the endpoint will accept request messages with
> response endpoint EPRs that contain something other than the
>
> anonymous URI as the value of [address]. This assertion is
> deliberately vague; it's presence indicates that a
> non-anonymous addresses might be accepted but doesn't
> constrain what such an address might look like. A receiver
> can still reject a request that contains an address that it
> doesn't understand or that requires a binding it doesn't
> support. As with the other assertions, the absence of the
> wsaw:NonAnonymousResponses policy assertion within a policy
>
> alternative does *not* indicate that the endpoint will not
> accept request messages with response endpoint EPRs that
> contain something other than the
>
> anonymous URI address.
>
> 3.2.3 Policy Examples
>
> The above policy assertions are designed to be used either
> independently or in conjunction with one another. The
> following examples illustrate some possible
> combinations:
>
> <wsp:Policy>
>   <wsaw:UsingAddressing>
> </wsp:Policy>
>
> This policy indicates that the subject supports the use of
> WS-Addressing.
> If a
> fault is generated as a result of sending a request message
> to an endpoint with this effective policy, that fault will
> not be due to the simple fact that the request message
> includes WS-Addressing headers. Note that nothing is said
> about either supporting or not supporting the use of
> anonymous or non-anonymous URIs.
>
> <wsp:Policy>
>   <wsaw:AnonymousResponses>
> </wsp:Policy>
>
> This policy indicates that the subject supports the use of
> WS-Addressing and, in particular, will accept request
> messages with response endpoint EPRs that contain the
> anonymous URI. If a fault is generated as a result of sending
> a request message to an endpoint with this effective policy,
> that fault will not be due to the fact that the request
> message includes WS-Addressing headers nor will it be due to
> the fact that the response endpoint EPRs contain the
> anonymous URI as an address. Note that nothing is said about
> either supporting or not supporting the use of non-anonymous URIs.
>
> <wsp:Policy>
>   <wsaw:UsingAddressing>
>   <wsaw:AnonymousResponses>
> </wsp:Policy>
>
> The above policy is semantically equivalent to the previous
> example. Note that this example could be the result of
> combining two separate policies (e.g.
> one
> attached at a wsdl:binding and the other at a wsdl20:endpoint (or
> wsdl11:port)) into a single effective policy.
>
> <wsp:Policy>
>   <wsaw:NonAnonymousResponses>
> </wsp:Policy>
>
> <wsp:Policy>
>   <wsaw:UsingAddressing>
>   <wsaw:NonAnonymousResponses>
> </wsp:Policy>
>
> The above two policies are identical ways of expressing the
> fact that the subject supports the use of WS-Addressing and,
> in particular, will accept request messages with response
> endpoint EPRs that contain URIs other than the anonymous URI.
> If a fault is generated as a result of sending a request
> message to an endpoint with either of these policies, that
> fault will not be due to the fact that the request message
> includes WS-Addressing headers nor will it be due to the mere
> fact that the response endpoint EPRs contain a non-anonymous
> URI as an address. Note that nothing is said about either
> supporting or not supporting the use of the anonymous URI.
>
> -------------
>
> - gp
>
>
>
>
>

Received on Monday, 4 December 2006 21:02:19 UTC