RE: First cut policy write up

See below. 
 

> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of 
> David Illsley
> Sent: Friday, Dec 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.
> 

I am really not following this point. Could you clarify?  

If you do not use wsp:optional and use the standard attachment
mechanisms, why wouldn't WS-Addressing be NOT required. 

IF there is no alternative in the policy, the intersection algorithm and
thus the client will treat WS-Addressing assertion as an addition that
it needs to understood and thus make behavior required. 

> 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. "
> 

I agree that the nested policy is what should be followed here. I was
about to write a very similar email, you beat me to it. 

> 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 Friday, 1 December 2006 22:43:21 UTC