W3C home > Mailing lists > Public > public-ws-policy@w3.org > May 2007

Re: policy vocabulary, will not be applied, oh my!

From: Monica J. Martin <Monica.Martin@Sun.COM>
Date: Fri, 04 May 2007 10:51:52 -0700
To: Sergey Beryozkin <sergey.beryozkin@iona.com>
Cc: David Orchard <dorchard@bea.com>, Christopher B Ferris <chrisfer@us.ibm.com>, public-ws-policy@w3.org, public-ws-policy-request@w3.org
Message-id: <463B72B8.8000801@sun.com>


>Sergey Beryozkin wrote:   
>Hi,
>"
>And voila, it knows exactly what it needs to do because it will pick one.  It will NOT do MessageSecurity and TransportSecurity because it doesn't have an alternative that lists that.  Again, this has the assumption that the client doesn't apply behaviours it knows about when they are not in the intersection result, but you could live without AIN by saying such behaviour is undefined and  "don't hit yourself with a pointy stick"."
>
>Seems like the simpliest approach. The intersected policy's vocabulary points to what can be applied.
>The client can choose to apply some other policy assertion, but IMHO suggesting that this is undefined would be the best possible message. This is because if the service provider has said :
><Policy>
>  <!-- sorry for using A&B :-) -->
>  <A/>
>  <B/>
></Policy>
>
>then I feel it doesn't mean that service does not support 'C'. It may support it. Or it may not support it. Omitting 'C' does not reliably indicate that 'C' is not supported. I can only see how omitting a given policy assertion can mean the negation when nested policies are used because this can be decided in scope of a given domain specific policy, for ex :
>
mm1: Agreed. The statements made in last week's teleconference and as 
alluded to with respect to Chris' proposal seemingly conflict if this 
was the intent.

><ws-addressing>
>   <Policy>
>        <anonumouseResponses/>
>   </Policy>
><ws-addressing>
>means that non-anonymous style is not supported...
>  
>
mm1: Actually, if you look at their Metadata document, this should be 
realigned a bit:

    <wsp:Policy>
        <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:ExactlyOne>
    </wsp:Policy>

It means that that Anonymous response type is required. You are 
restricted from having the two response types in the same alternative 
explicitly in the nested policy expression (explicitly mutually 
exclusive). Yet for the one below, the semantics are inclusive.

    <wsp:Policy>
        <wsam:Addressing>
            <wsp:Policy/>
        </wsam:Addressing>
    </wsp:Policy>

The wsam:Addressing policy assertion is inclusive - you can support 
WS-Addressing and the SOAP binding without qualification (not 
constraints on the support for either).

>but if I say
>
><Policy>
>    <TransportSecurity/>
></Policy>
>
>it does not mean that the client can not do MTOM, it may or may not be able to succesfully send MTOMs
>Thanks, Sergey
>  
>
mm1: This brings up if differences exist between a policy assertion and any nested policy expression in their semantics here (Tom Rutt's global or local context). It also raises a question whether the assumptions are consistent within or across domains. I wonder if nesting could be like a container or a dependent constraint (or both or other?).
Received on Friday, 4 May 2007 17:51:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:34 UTC