This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 4393 - [Primer] Add text to strict and lax policy intersection discussion describing how a policy consumer can determine issues due to intersection mode conflicts
Summary: [Primer] Add text to strict and lax policy intersection discussion describing...
Status: RESOLVED FIXED
Alias: None
Product: WS-Policy
Classification: Unclassified
Component: Primer (show other bugs)
Version: PR
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Felix Sasaki
QA Contact: Web Services Policy WG QA List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-03-14 17:42 UTC by Charlton Barreto
Modified: 2007-04-25 17:05 UTC (History)
0 users

See Also:


Attachments

Description Charlton Barreto 2007-03-14 17:42:47 UTC
Title: Need to provide some text in the Primer to describe how a policy consumer can determine issues due to intersection mode conflicts as per the resolution to Issue 4292 (http://www.w3.org/2007/03/14-ws-policy-irc#T17-13-34). 

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: Add text to the Primer (3.4.1 Strict and Lax Policy Intersection) that a consumer can compare the intersection results from applying both strict and lax mode, and analyse what drops out from that application to detect conflicts and specify their source.
Comment 1 Charlton Barreto 2007-03-27 23:49:26 UTC
Update - concrete proposal: 
Perform the following changes to the Primer text

Change in 3.4.1 Strict and Lax Policy Intersection, in the 3rd paragraph, 4th sentence as follows:

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

Add to 3.4.1 Strict and Lax Policy Intersection, after the 4th paragraph as follows:

"In certain cases the provider may intend for their policy or policies to be intersected using one mode, while a requestor may not support that same mode while they both have expectations on expected results. For example, a provider of a service which handles line of business (LOB) processing can provide a number of qualities of service (QoS) which are exposed as policies. A requestor can effectively navigate which QoS (service interface) to use through its requirements. 
However, the requestor of an LOB processing service may need to consistently apply certain assertions in order to use a service, whether these are the requestors own, or accepted from the provider. In particular, requestors which require strict mode intersection could encounter unnecessary intersection results such as failures (no policy alternatives available) without any information as to why the failure occurred. In such cases it is useful for the requestors to apply multiple intersection modes when consuming policies and comparing the results, in order to detect conflicts and specify their source.

Regardless of chosen policy intersection mode, the wsp:Ignorable marker on a policy assertion 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, and are not ignored, regardless whether those assertions are marked with wsp:Ignorable."
Comment 2 Monica Martin 2007-04-25 16:17:44 UTC
Updated minor changes to answer Glen Daniel's question from 18 April 2007 conference call, see resolution: http://lists.w3.org/Archives/Public/public-ws-policy/2007Apr/0055.html

   [change from / Glen's] "Regardless of the chosen intersection mode,
   ignorable assertions do not express any concrete requirements on the
   behavior of consumers - in other words, a consumer is free to ignore
   (hence the name "ignorable") any such assertions that end up in the
   resulting policy after interesection, with no adverse effects on
   runtime interactions."

   [change to / updated] "Regardless of the chosen intersection mode,
   ignorable assertions do not express any wire-level requirements on
   the behavior of consumers - in other words, a consumer could choose
   to ignore any such assertions that end up in the resulting policy
   after interesection, with no adverse effects on runtime interactions."
Comment 4 Charlton Barreto 2007-04-25 17:05:53 UTC
The resolution detailed in http://lists.w3.org/Archives/Public/public-ws-policy/2007Apr/0057.html is as follows (for reference w.r.t. this bug):

Last week we took an action item to revise the proposal for 4393 to address issue 280, amending the text we agreed on at the 2007-04-11 telcon to address Glens concerns w.r.t. ignorable.

After discussion last week we have developed an amendment. The amended proposal is below:

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 and bracketed with <<>> 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, all assertions are part of the policy alternative vocabulary, including those marked with wsp:Ignorable. Thus, the wsp:Ignorable attribute does not impact the intersection result even when its 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 the chosen intersection mode, ignorable assertions do not express any wire-level requirements on the behavior of consumers - in other words, a consumer could choose   to ignore any such assertions that end up in the resulting policy after intersection, with no adverse effects on runtime interactions.>>

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

A requester can decide how to process a provider's policy to determine if and how the requester will interact with the provider. The requester can have its own policy that expresses its own capabilities and requirements, and can make one or more attempts at policy intersection in order to determine a compatible alternative and/or isolate the cause of an empty intersection result. The requester can use and analyze the result(s) of policy intersection to select a compatible alternative or trigger other domain-specific processing options. For example, a requester can at first attempt strict mode intersection, and then lax mode as another choice, if the previous attempt returns an empty intersection result."