RE: [Bug 4554] Configurability and comformance of intersection algorithm

>It's not clear that they're even
>obligated to support the "approximation".

Policy intersection is a useful tool when two or more parties express policy and want to limit the policy alternatives to those that are mutually compatible. The use of policy intersection is optional.

>The use of "approximation" is also unsettling

It is a QName based approximation. If implementers would like to use policy intersection as the default algorithm they are free to make it so.

>Should there be different behavior for strict and lax modes, or can it
>be ignored for a given vocabulary?

We think you are referring to the behavior implied by an assertion. If so, the behavior implied by an assertion is independent of the chosen intersection mode.

>What if an alternative contains assertions from two different
>vocabularies, each with its own domain-specific rules, and these rules
>conflict in some way?

Possible. We think assertion authors should avoid defining conflicting domain specific intersection rules. If there are any conflicting rules, implementers should provide feedback to the assertion authors.

We hope this helps.

Regards,

Asir S Vedamuthu
Microsoft Corporation


-----Original Message-----
From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Paul Cotton
Sent: Sunday, May 13, 2007 12:20 PM
To: public-ws-policy@w3.org
Cc: dmh@tibco.com
Subject: [Bug 4554] Configurability and comformance of intersection algorithm



-----Original Message-----
From: public-ws-policy-qa-request@w3.org [mailto:public-ws-policy-qa-request@w3.org] On Behalf Of bugzilla@wiggum.w3.org
Sent: May 11, 2007 11:47 AM
To: public-ws-policy-qa@w3.org
Subject: [Bug 4554] Configurability and comformance of intersection algorithm


http://www.w3.org/Bugs/Public/show_bug.cgi?id=4554

           Summary: Configurability and comformance of intersection
                    algorithm
           Product: WS-Policy
           Version: CR
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Framework
        AssignedTo: fsasaki@w3.org
        ReportedBy: dmh@tibco.com
         QAContact: public-ws-policy-qa@w3.org


It is not clear to what extent the intersection algorithm may be extended or
what obligation processors have to support these extensions.

The second paragraph of section 4.5 reads

"... 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 ... As a first approximation, an algorithm is defined
herein that approximates compatibility in a domain-independent manner."

As far as I can tell, the intent here is that the determination of
compatibility is domain-specific, and that by default the rules go by the type
of the assertions in the alternative and in the case of lax mode, whether the
assertions are marked as optional.

However, even this much is not completely clear, as the text mentions
"domain-specific intersection processing".  So conceivably not only the
compatibility of two alternatives but the result of intersecting them if they
are compatible could be domain specific.

The use of "approximation" is also unsettling in a specifications.  I suspect
it might mean "default" here, but I'm not sure.

In any case, it is not at all clear what leeway someone defining a policy
vocabulary has.  Should there be different behavior for strict and lax modes,
or can it be ignored for a given vocabulary?  Must the intersection itself
follow the "all assertions in both alternatives" rule (subject to
clarification, see 4553)?  What if an alternative contains assertions from two
different vocabularies, each with its own domain-specific rules, and these
rules conflict in some way?

Given clear answers to these questions of definition, what obligations are
processors under to support any of this?  It's not clear that they're even
obligated to support the "approximation".  I see no MUST -- perhaps this is
covered under policy attachment or elsewhere?

Received on Thursday, 17 May 2007 01:35:41 UTC