W3C home > Mailing lists > Public > public-ws-policy@w3.org > April 2007

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

From: Monica J. Martin <Monica.Martin@Sun.COM>
Date: Wed, 04 Apr 2007 09:11:46 -0700
To: public-ws-policy@w3.org
Message-id: <4613CE42.7080007@sun.com>

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

Barreto proposal for Issue 4393: 

> 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:33 UTC