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

[Using plain text format]

>Is there a worked-through example of where and how the result of intersection would be useful?

The Primer carries such an illustrative example in Section 3.4 [1].

[1] http://www.w3.org/TR/2007/WD-ws-policy-primer-20070330/#compatible-policies

> If not, I would expect to see OPTIONAL.

Okay. How about - s/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./Policy intersection is OPTIONAL and is a useful tool when two or more parties express policy and want to limit the policy alternatives to those that are mutually compatible./

>IMO it would be less confusing to say "This is the default policy
>intersection behavior" instead of calling it an approximation.

The policy intersection is OPTIONAL and is a QName based approximation. Given these, the policy intersection cannot be labeled as the default.

>By default ("approximation"?) assertions marked ignorable participate
>in strict intersection but not in lax intersection.  Could I define a
>new assertion and state "this assertion MUST be considered in lax
>intersection, even if marked ignorable?"  (I would hope not.  It would
>be clearer in such a case to say "this assertion MUST NOT be marked ignorable")

Your observation is correct. In this case, the onus is on the assertion author. If an assertion author wants an assertion to be processed by policy intersection the assertion should not be marked ignorable. This is a good point that we could cover in the Guidelines for Assertion Authors document.

>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. This is also a good point that we could cover in the Guidelines for Assertion Authors document.

Regards,

Asir S Vedamuthu
Microsoft Corporation








From: David Hull [mailto:dmh@tibco.com]
Sent: Wednesday, May 16, 2007 8:58 PM
To: Asir Vedamuthu
Cc: Paul Cotton; public-ws-policy@w3.org
Subject: Re: [Bug 4554] Configurability and comformance of intersection algorithm

Asir Vedamuthu wrote:
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.

Yes, about that: Is there a worked-through example of where and how the result of intersection would be useful?  By "result" I mean literally the result.

The framework speaks of checking whether the intersection of two policies is empty, and the primer refers to  using intersection to learn which desired alternatives are compatible with a given policy.

As far as I can this compatibility checking is the useful functionality, indeed the whole point of having a policy framework in the first place.  Given this, it doesn't seem to matter whether policies and alternatives are bags or sets, or whether the "intersection" of two alternatives is the bag union, the set union or simply a boolean that says whether they were compatible.

 The use of policy intersection is optional.

By "use", do you mean "use by client code" or "support by processors"?  Does "I support WS-Policy" mean "I support the version of intersection given in section 4 of the framework (and possibly some extensions)"?  If so, I would expect to see an RFC2119 MUST somewhere in that section.  If not, I would expect to see 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.

The point is that, from a literal reading, it doesn't seem that the framework defines policy intersection at all.  It defines an operation that is said to be an approximation of it, but it doesn't define the operation itself.

I believe this is a purely editorial issue; clearly the framework defines something.  IMO it would be less confusing to say "This is the default policy intersection behavior" instead of calling it an approximation.  I'm also arguing that it should go on to define in what ways this default behavior may be modified and the result still be called policy intersection.



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.

No, that's not what I mean.

By default ("approximation"?) assertions marked ignorable participate in strict intersection but not in lax intersection.  Could I define a new assertion and state "this assertion MUST be considered in lax intersection, even if marked ignorable?"  (I would hope not.  It would be clearer in such a case to say "this assertion MUST NOT be marked ignorable")

Or, could I say "If this assertion is marked ignorable, it MUST be considered incompatible with assertion XYZ regardless of the value of the ignorable attribute"?  That is, I'm disabling the strict/lax distinction but only in certain cases.



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.

That seems reasonable, and worth an RFC 2119 SHOULD NOT.


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 Wednesday, 23 May 2007 05:05:04 UTC