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?
>
>
>