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: Charlton Barreto <barreto@adobe.com>
Date: Tue, 3 Apr 2007 16:56:46 -0700
Message-ID: <0911261107CC9648A12399E739C6BEC2636586@namail5.corp.adobe.com>
To: <public-ws-policy@w3.org>
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

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

Domain-specific processing could take advantage of any information from
the policy data model, such as the ignorable property of a policy

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."






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


(image/gif attachment: image001.gif)

Received on Tuesday, 3 April 2007 23:57:21 UTC

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