- From: Tom Rutt <tom@coastin.com>
- Date: Thu, 30 Nov 2006 02:16:44 +0900
- To: public-ws-addressing@w3.org
I sent the following mail to the wrong list on monday. I talked about it, but now i resend it on the addressing list. ----------- I took the following action item from last week's call: *ACTION:* TomRutt to check with Ws-Policy groups on potential problems with nesting The latest proposals are not actually using nested policy assertions but are using policy assertions with parameters. e.g.: <wsp:Policy> <wsaw:AddressingRequired> <wsaw:NoAnonymousReplies/> </wsaw:AddressingRequired> </wsp:Policy> On investigation, it seems to me now that an essential affect this inclusion of policy parameters has over separate policy assertions for the two aspects is with regards to the default policy intersection algorithm. I quote from section 4.5 of ws-policy framework http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.html " 4.5 Policy Intersection Policy intersection is useful when two or more parties express policy and want to limit the policy alternatives to those that are mutually compatible. For example, when a requester and a provider express requirements on a message exchange, intersection identifies compatible policy alternatives (if any) included in both requester and provider policies. Intersection is a commutative function that takes two policies and returns a policy. There are two modes for intersection: strict and lax. How the mode is selected or indicated for the policy intersection is outside the scope of this specification. Because the set of behaviors indicated by a policy alternative depends on the domain-specific semantics of the collected assertions, determining whether two policy alternatives are compatible generally involves domain-specific processing. If a domain-specific intersection processing algorithm is required this will be known from the QNames of the specific assertion types involved in the policy alternatives. As a first approximation, an algorithm is defined herein that approximates compatibility in a domain-independent manner: * Two policy assertions are compatible if they have the same type and * If either assertion contains a nested policy expression, the two assertions are compatible if they both have a nested policy expression and the alternative in the nested policy expression of one is compatible with the alternative in the nested policy expression of the other. Assertion parameters are not part of the compatibility determination defined herein but may be part of other, domain-specific compatibility processing. " Thus the policy assertion with Qname <wsaw:AddressingRequired> would be considered compatible with any other assertion with that Qname, independent of the including of any child policy parameters (e.g., If AnonymousReplies parm is in one assertion of type addressingRequired and noAnonymousReplies is in another of type addressingRequire, the two assertions would be considered compatible). If the "anonymous vs non anonymous" policy indication was a separate high level assertion type than the addressingRequired assertion type, the the default intersection algorithm would give a different result. I have not taken the time to try to determin if this difference is significant for WS-addressing, but I would like to have this action item closed with this response. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
Received on Wednesday, 29 November 2006 17:19:31 UTC