delayed Action Item response re Policy nesting

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