[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

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4393





------- Comment #4 from cbarreto@adobe.com  2007-04-25 17:05 -------
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
Glen’s 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."

Received on Wednesday, 25 April 2007 17:06:08 UTC