Re: [ISSUE 4393 PRIMER] Add text to strict and lax policy intersection discussion ...

This also updates my action related to Issue 4262 (that was closed, 
related to the Primer). Thanks.




Barreto proposal for Issue 4393: 
http://lists.w3.org/Archives/Public/public-ws-policy/2007Apr/0004.html

> Charlton Barreto wrote: See: 
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=4393
>
> Title: Add text to strict and lax policy intersection discussion 
> describing how a policy consumer can determine issues due to 
> intersection mode conflicts
>
> Target: WS-Policy Primer, Section 3.4.1
>
> Description: While the Primer covers scenarios on applying 
> intersection modes, we do not have any content which illustrates how 
> conflicts can be detected. As such we need to indicate in the Primer 
> how a consumer may address such conflict detection and reporting.
>
> Justification: As consumers have the option to choose one or more 
> modes for policy intersection (strict | lax | strict, delegate-to-user 
> | lax, delegate-to-user | strict, lax, delegate-to-user | ...), 
> conflicts may occur when providers intend for their policies to be 
> applied only in a lax mode - this is distinct from treating everything 
> as ignorable. While the end result may be the same (failure, being 
> that no policy alternatives are available), the consumer needs to be 
> able to report
>
> why this occurs.
>
> Proposal: Perform the following changes to the Primer text
>
> Change in 3.4.1 Strict and Lax Policy Intersection, as follows 
> (highlighted in colour below):
>
> “The previous sections outlined how the normal-form of a policy 
> expression relate to the policy data model and how the compatibility 
> of requester and provider policies may be determined. This section 
> outlines how ignorable assertions may impact the process of 
> determining compatibility.
>
> In order to determine compatibility of its policy expression with a 
> provider policy expression, a requester may use either a "lax" or 
> "strict" mode of the intersection algorithm.
>
> In the strict intersection mode two policy alternatives are compatible 
> when each assertion in one is compatible with an assertion in the 
> other, and vice versa. For this to be possible they must share the 
> same policy alternative vocabulary. The strict intersection mode is 
> the mode of intersection discussed in the previous sections of this 
> document.
>
> When using the strict intersection mode, assertions marked with 
> wsp:Ignorable are part of the policy alternative vocabulary, so the 
> wsp:Ignorable attribute does not impact the intersection result even 
> when the wsp:Ignorable attribute value is “true”.
>
> If a requester wishes to ignore ignorable assertions in a provider's 
> policy, then the requester should use the lax intersection mode. In 
> the lax intersection mode all ignorable assertions (i.e. with the 
> value "true" for the wsp:Ignorable attribute) are to be ignored by the 
> intersection algorithm. Thus in the lax intersection mode two policy 
> alternatives are compatible when each non-ignorable assertion in one 
> is compatible with an assertion in the other, and vice versa. For this 
> to be possible the two policy alternatives must share a policy 
> alternative vocabulary for all “non-ignorable” assertions.
>
> Regardless of chosen policy intersection mode, a policy assertion 
> marked with wsp:Ignorable attribute does not express any requirement 
> on the behavior of the client, rather, it is used for intersection as 
> indicated in Section 2.7. After intersection, any assertions contained 
> in the resulting policy that are understood by the client are handled 
> as expected behaviors. As part of the policy expression, these 
> behaviors are not ignored, regardless of whether those assertions are 
> marked with wsp:Ignorable.
>
> Domain-specific processing could take advantage of any information 
> from the policy data model, such as the ignorable property of a policy 
> assertion.
>
> Domain specific processing can be used by a requestor to effectively 
> navigate which QoS (service interface) to use through its 
> requirements. The requestor may need to consistently apply certain 
> assertions in order to use that service, whether these are the 
> requestor's own, or accepted from the provider.
>
> Domain specific processing by a requestor can also provide a way to 
> trigger alternate processing options when no alternatives are 
> available from the intersection alone. The requestor could be 
> presented with the result to determine an acceptable alternative. For 
> example, in strict mode intersection, no alternatives may be available 
> as a product of the intersection to the requestor. The requestor can 
> then make additional attempts at intersection in order to isolate the 
> cause and/or determine an acceptable alternative.”
>
> Thanks,
>
> -Charlton.
>
> 	
>
> *Charlton Barreto*
> Senior Computer Scientist
> Adobe Systems Incorporated
> 345 Park Avenue, MS E15
> San Jose, CA 95110-2704 USA
> 408.536.4496 p
> 415.692.5396 m
> charltonb@adobe.com
>

Received on Wednesday, 4 April 2007 16:25:11 UTC